https://wiki.archlinux.org/api.php?action=feedcontributions&user=Lseubert&feedformat=atomArchWiki - User contributions [en]2024-03-29T07:46:48ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=User:Lseubert&diff=251932User:Lseubert2013-03-25T18:19:27Z<p>Lseubert: /* To Do */</p>
<hr />
<div>=Arch Wiki Curriculum Vitae=<br />
<br />
===To Do===<br />
#https://wiki.archlinux.org/index.php/CDM - Update to SystemD - refers to init and rc.conf<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have started:===<br />
<br />
#[http://wiki.archlinux.org/index.php/Enhancing_Arch_Linux_Stability Enhancing Arch Linux Stability]<br />
#[http://wiki.archlinux.org/index.php/Open_ERP Open ERP]<br />
#[http://wiki.archlinux.org/index.php/History_of_Arch_Linux History of Arch Linux]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I am currently working on:===<br />
#[http://wiki.archlinux.org/index.php/Open_ERP Open ERP]<br />
#[http://wiki.archlinux.org/index.php/History_of_Arch_Linux History of Arch Linux]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have made major revisions to:===<br />
#[http://wiki.archlinux.org/index.php/Arch-based_Distros Arch-based Distros] The previous version [http://wiki.archlinux.org/index.php?title=Arch-based_Distros&oldid=69020 was this.]<br />
#[http://wiki.archlinux.org/index.php/Arch_Linux_Press_Review Arch Linux Press Review] The previous version [http://wiki.archlinux.org/index.php?title=Arch_Linux_Press_Review&oldid=52209 was this.]<br />
#[http://wiki.archlinux.org/index.php/Licenses Licenses] The previous version [http://wiki.archlinux.org/index.php?title=Licenses&oldid=31564 was this.]<br />
#[http://wiki.archlinux.org/index.php/AUR_Helpers AUR Helpers] The previous version [http://wiki.archlinux.org/index.php?title=AUR_Helpers&oldid=69391 was this.]<br />
#[http://wiki.archlinux.org/index.php/Pacman_GUI_Frontends Pacman GUI Frontends] The previous version [http://wiki.archlinux.org/index.php?title=Pacman_GUI_Frontends&oldid=70128 was this.]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have contributed to:===<br />
<br />
#[http://wiki.archlinux.org/index.php/Unofficial_user_repositories Unofficial user repositories]<br />
<br><br />
<br />
===Arch Wikipages that I have tweaked slightly:===<br />
#[http://wiki.archlinux.org/index.php/Community_Projects Community Projects]<br />
#[http://wiki.archlinux.org/index.php/How_to_become_an_Arch_developer How to become an Arch Developer]<br />
#[http://wiki.archlinux.org/index.php/Mutualism_Arch Mutualism Arch]<br />
#[http://wiki.archlinux.de/title/Arch_in_den_Medien Arch in den Medien]<br />
#[http://wiki.archlinux.org/index.php/Enlightenment Enlightenment]<br />
#[http://wiki.archlinux.org/index.php/ABS_-_The_Arch_Build_System ABS - The Arch Build System]<br />
#[http://wiki.archlinux.org/index.php/Makepkg Makepkg]<br />
<br><br />
<br />
===Arch Wikipages that I have helped to merge:===<br />
<br />
#In discussion - proposed but not yet completed merger of: [http://wiki.archlinux.org/index.php/Community_Projects Community Projects], [http://wiki.archlinux.org/index.php/How_to_become_an_Arch_developer How to become an Arch developer], and [http://wiki.archlinux.org/index.php/Mutualism_Arch Mutualism Arch].<br />
<br></div>Lseuberthttps://wiki.archlinux.org/index.php?title=User:Lseubert&diff=251930User:Lseubert2013-03-25T18:17:43Z<p>Lseubert: /* Arch Wiki Curriculum Vitae */</p>
<hr />
<div>=Arch Wiki Curriculum Vitae=<br />
<br />
===To Do===<br />
#[https://wiki.archlinux.org/index.php/CDM] - Update to SystemD - refers to init and rc.conf<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have started:===<br />
<br />
#[http://wiki.archlinux.org/index.php/Enhancing_Arch_Linux_Stability Enhancing Arch Linux Stability]<br />
#[http://wiki.archlinux.org/index.php/Open_ERP Open ERP]<br />
#[http://wiki.archlinux.org/index.php/History_of_Arch_Linux History of Arch Linux]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I am currently working on:===<br />
#[http://wiki.archlinux.org/index.php/Open_ERP Open ERP]<br />
#[http://wiki.archlinux.org/index.php/History_of_Arch_Linux History of Arch Linux]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have made major revisions to:===<br />
#[http://wiki.archlinux.org/index.php/Arch-based_Distros Arch-based Distros] The previous version [http://wiki.archlinux.org/index.php?title=Arch-based_Distros&oldid=69020 was this.]<br />
#[http://wiki.archlinux.org/index.php/Arch_Linux_Press_Review Arch Linux Press Review] The previous version [http://wiki.archlinux.org/index.php?title=Arch_Linux_Press_Review&oldid=52209 was this.]<br />
#[http://wiki.archlinux.org/index.php/Licenses Licenses] The previous version [http://wiki.archlinux.org/index.php?title=Licenses&oldid=31564 was this.]<br />
#[http://wiki.archlinux.org/index.php/AUR_Helpers AUR Helpers] The previous version [http://wiki.archlinux.org/index.php?title=AUR_Helpers&oldid=69391 was this.]<br />
#[http://wiki.archlinux.org/index.php/Pacman_GUI_Frontends Pacman GUI Frontends] The previous version [http://wiki.archlinux.org/index.php?title=Pacman_GUI_Frontends&oldid=70128 was this.]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have contributed to:===<br />
<br />
#[http://wiki.archlinux.org/index.php/Unofficial_user_repositories Unofficial user repositories]<br />
<br><br />
<br />
===Arch Wikipages that I have tweaked slightly:===<br />
#[http://wiki.archlinux.org/index.php/Community_Projects Community Projects]<br />
#[http://wiki.archlinux.org/index.php/How_to_become_an_Arch_developer How to become an Arch Developer]<br />
#[http://wiki.archlinux.org/index.php/Mutualism_Arch Mutualism Arch]<br />
#[http://wiki.archlinux.de/title/Arch_in_den_Medien Arch in den Medien]<br />
#[http://wiki.archlinux.org/index.php/Enlightenment Enlightenment]<br />
#[http://wiki.archlinux.org/index.php/ABS_-_The_Arch_Build_System ABS - The Arch Build System]<br />
#[http://wiki.archlinux.org/index.php/Makepkg Makepkg]<br />
<br><br />
<br />
===Arch Wikipages that I have helped to merge:===<br />
<br />
#In discussion - proposed but not yet completed merger of: [http://wiki.archlinux.org/index.php/Community_Projects Community Projects], [http://wiki.archlinux.org/index.php/How_to_become_an_Arch_developer How to become an Arch developer], and [http://wiki.archlinux.org/index.php/Mutualism_Arch Mutualism Arch].<br />
<br></div>Lseuberthttps://wiki.archlinux.org/index.php?title=User:Lseubert&diff=250401User:Lseubert2013-03-12T21:21:36Z<p>Lseubert: /* Arch Wikipages that I am currently working on: */</p>
<hr />
<div>=Arch Wiki Curriculum Vitae=<br />
<br />
===Arch Wikipages that I have started:===<br />
<br />
#[http://wiki.archlinux.org/index.php/Enhancing_Arch_Linux_Stability Enhancing Arch Linux Stability]<br />
#[http://wiki.archlinux.org/index.php/Open_ERP Open ERP]<br />
#[http://wiki.archlinux.org/index.php/History_of_Arch_Linux History of Arch Linux]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I am currently working on:===<br />
#[http://wiki.archlinux.org/index.php/Open_ERP Open ERP]<br />
#[http://wiki.archlinux.org/index.php/History_of_Arch_Linux History of Arch Linux]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have made major revisions to:===<br />
#[http://wiki.archlinux.org/index.php/Arch-based_Distros Arch-based Distros] The previous version [http://wiki.archlinux.org/index.php?title=Arch-based_Distros&oldid=69020 was this.]<br />
#[http://wiki.archlinux.org/index.php/Arch_Linux_Press_Review Arch Linux Press Review] The previous version [http://wiki.archlinux.org/index.php?title=Arch_Linux_Press_Review&oldid=52209 was this.]<br />
#[http://wiki.archlinux.org/index.php/Licenses Licenses] The previous version [http://wiki.archlinux.org/index.php?title=Licenses&oldid=31564 was this.]<br />
#[http://wiki.archlinux.org/index.php/AUR_Helpers AUR Helpers] The previous version [http://wiki.archlinux.org/index.php?title=AUR_Helpers&oldid=69391 was this.]<br />
#[http://wiki.archlinux.org/index.php/Pacman_GUI_Frontends Pacman GUI Frontends] The previous version [http://wiki.archlinux.org/index.php?title=Pacman_GUI_Frontends&oldid=70128 was this.]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have contributed to:===<br />
<br />
#[http://wiki.archlinux.org/index.php/Unofficial_user_repositories Unofficial user repositories]<br />
<br><br />
<br />
===Arch Wikipages that I have tweaked slightly:===<br />
#[http://wiki.archlinux.org/index.php/Community_Projects Community Projects]<br />
#[http://wiki.archlinux.org/index.php/How_to_become_an_Arch_developer How to become an Arch Developer]<br />
#[http://wiki.archlinux.org/index.php/Mutualism_Arch Mutualism Arch]<br />
#[http://wiki.archlinux.de/title/Arch_in_den_Medien Arch in den Medien]<br />
#[http://wiki.archlinux.org/index.php/Enlightenment Enlightenment]<br />
#[http://wiki.archlinux.org/index.php/ABS_-_The_Arch_Build_System ABS - The Arch Build System]<br />
#[http://wiki.archlinux.org/index.php/Makepkg Makepkg]<br />
<br><br />
<br />
===Arch Wikipages that I have helped to merge:===<br />
<br />
#In discussion - proposed but not yet completed merger of: [http://wiki.archlinux.org/index.php/Community_Projects Community Projects], [http://wiki.archlinux.org/index.php/How_to_become_an_Arch_developer How to become an Arch developer], and [http://wiki.archlinux.org/index.php/Mutualism_Arch Mutualism Arch].<br />
<br></div>Lseuberthttps://wiki.archlinux.org/index.php?title=AUR_helpers/Graphical&diff=85616AUR helpers/Graphical2009-11-28T13:33:00Z<p>Lseubert: /* GtkPacman */ Inserted new screenshot link for GtkPacman</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:Utilities (English)]]<br />
[[Category:General (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English| Pacman_GUI_Frontends}}<br />
{{i18n_entry|简体中文| Pacman_GUI_Frontends_(简体中文)}}<br />
{{i18n_entry|Türkçe| Pacman Ön Yüzleri (Türkçe)}}<br />
{{i18n_links_end}}<br />
This is a list of Pacman GUI frontends, designed to provide a graphical version of the CLI tool, pacman. The list includes Gtk2 based software, Qt based software, and a variety of System Tray Notifiers. None of these tools are officially supported.<br />
<br />
= Gnome/Gtk2 Pacman GUI Software =<br />
<br />
===GtkPacman===<br />
<br />
GtkPacman is a simple, but powerful frontend to the Arch Linux pacman. It is written in python, using pygtk, and is fast and stable. With gtkPacman, system management becomes matter of a button press. The last release for GtkPacman was in February, 2008.<br />
<br />
*Homepage: http://gtkpacman.berlios.de/ <br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=8027<br />
*Screenshots: http://developer.berlios.de/screenshots/?group_id=4808<br />
<br><br />
<br />
= KDE/Qt Pacman GUI Software =<br />
<br />
===Shaman===<br />
<br />
Shaman is a GUI for Arch Linux package handling. It is based on libalpm. This has a lot of advantages, from integration to speed. Also, queries and searches are performed faster than pacman, and with a high level of customization. Shaman can do everything a package manager usually does, including: <br />
:Installing/removing/upgrading packages<br />
:Searching/filtering packages<br />
:Package information<br />
:Database maintenance tasks<br />
<br />
Additionally Shaman supports time based database updates, a RSS-feed reader for Arch Linux package news and editing the pacman configuration files.<br />
<br />
*Homepage: http://chakra-project.org/tools-shaman.html<br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=15422<br />
*Screenshots: http://chakra-project.org/screenshots/tools_shaman.png<br />
<br><br />
<br />
= System Tray Notifiers =<br />
<br />
===Chase===<br />
<br />
Chase is a notification daemon for KDE4, created by the chakra project, Chase uses libapm to manage updates, is fully configurable and integrated with Shaman and the KDE4 desktop environment<br />
<br />
*Homepage: http://chakra-project.org/bbs/viewtopic.php?id=1303<br />
*AUR package details: http://aur.archlinux.org/packages.php?ID=29567<br />
*Screenshots: http://chakra-project.org/bbs/viewtopic.php?id=1303<br />
<br />
===alunn===<br />
<br />
alunn is a simple notification applet for the Arch Linux distribution. It will notify you whenever there are new package updates ready for Pacman or when news appear on the Arch Linux frontpage. Customizable commands to upgrade the system or read the news can be executed when clicking the notification icon.<br />
<br />
*Homepage: http://nedrebo.org/code/alunn/<br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=6098<br />
*Screenshots: http://nedrebo.org/code/alunn/<br />
<br />
===pacman-notifier===<br />
<br />
Written in Ruby, uses Gtk. Shows an icon in the system tray and popup notifications (using libnotify) for new packages.<br />
<br />
*Homepage: http://code.google.com/p/pacman-notifier/<br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=15193<br />
*Screenshots: http://code.google.com/p/pacman-notifier/<br />
<br />
===pacupdate===<br />
<br />
Pacupdate is a small application that notifies the user about new updates for Arch Linux. If pacupdate finds out that a update is available, it will display a notification in SystemTray.<br />
<br />
*Homepage: http://code.google.com/p/pacupdate/<br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=19068<br />
*Screenshots: <br />
<br />
===ZenMan===<br />
<br />
PacMan frontend (tray update notifier) for GTK/GNOME/zenity/libnotify.<br />
<br />
*Homepage:<br />
*AUR Package Details:http://aur.archlinux.org/packages.php?ID=25948<br />
*Screenshots:http://show.harvie.cz/screenshots/zenman-screenshot-2.png<br />
<br><br />
<br />
= Inactive Software Packages =<br />
*[http://guzuta.berlios.de/ Guzuta]<br />
*[https://opensvn.csie.org/PacmanManager/ PacmanManager]<br />
*[http://code.google.com/p/pacmon/ pacmon]<br />
*[https://gna.org/projects/paku/ Paku]<br />
*[http://www.kde-apps.org/content/show.php/YAPG+-+Yet+Another+Pacman+Gui+?content=60052 YAPG]<br />
*[http://sourceforge.net/projects/zenitypacgui/ zenity_pacgui]</div>Lseuberthttps://wiki.archlinux.org/index.php?title=AUR_helpers/Graphical&diff=85615AUR helpers/Graphical2009-11-28T13:30:02Z<p>Lseubert: /* GtkPacman */ Inserted last release date for GtkPacman. Removed dead screenshot link.</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:Utilities (English)]]<br />
[[Category:General (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English| Pacman_GUI_Frontends}}<br />
{{i18n_entry|简体中文| Pacman_GUI_Frontends_(简体中文)}}<br />
{{i18n_entry|Türkçe| Pacman Ön Yüzleri (Türkçe)}}<br />
{{i18n_links_end}}<br />
This is a list of Pacman GUI frontends, designed to provide a graphical version of the CLI tool, pacman. The list includes Gtk2 based software, Qt based software, and a variety of System Tray Notifiers. None of these tools are officially supported.<br />
<br />
= Gnome/Gtk2 Pacman GUI Software =<br />
<br />
===GtkPacman===<br />
<br />
GtkPacman is a simple, but powerful frontend to the Arch Linux pacman. It is written in python, using pygtk, and is fast and stable. With gtkPacman, system management becomes matter of a button press. The last release for GtkPacman was in February, 2008.<br />
<br />
*Homepage: http://gtkpacman.berlios.de/ <br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=8027<br />
*Screenshots: <br />
<br><br />
<br />
= KDE/Qt Pacman GUI Software =<br />
<br />
===Shaman===<br />
<br />
Shaman is a GUI for Arch Linux package handling. It is based on libalpm. This has a lot of advantages, from integration to speed. Also, queries and searches are performed faster than pacman, and with a high level of customization. Shaman can do everything a package manager usually does, including: <br />
:Installing/removing/upgrading packages<br />
:Searching/filtering packages<br />
:Package information<br />
:Database maintenance tasks<br />
<br />
Additionally Shaman supports time based database updates, a RSS-feed reader for Arch Linux package news and editing the pacman configuration files.<br />
<br />
*Homepage: http://chakra-project.org/tools-shaman.html<br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=15422<br />
*Screenshots: http://chakra-project.org/screenshots/tools_shaman.png<br />
<br><br />
<br />
= System Tray Notifiers =<br />
<br />
===Chase===<br />
<br />
Chase is a notification daemon for KDE4, created by the chakra project, Chase uses libapm to manage updates, is fully configurable and integrated with Shaman and the KDE4 desktop environment<br />
<br />
*Homepage: http://chakra-project.org/bbs/viewtopic.php?id=1303<br />
*AUR package details: http://aur.archlinux.org/packages.php?ID=29567<br />
*Screenshots: http://chakra-project.org/bbs/viewtopic.php?id=1303<br />
<br />
===alunn===<br />
<br />
alunn is a simple notification applet for the Arch Linux distribution. It will notify you whenever there are new package updates ready for Pacman or when news appear on the Arch Linux frontpage. Customizable commands to upgrade the system or read the news can be executed when clicking the notification icon.<br />
<br />
*Homepage: http://nedrebo.org/code/alunn/<br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=6098<br />
*Screenshots: http://nedrebo.org/code/alunn/<br />
<br />
===pacman-notifier===<br />
<br />
Written in Ruby, uses Gtk. Shows an icon in the system tray and popup notifications (using libnotify) for new packages.<br />
<br />
*Homepage: http://code.google.com/p/pacman-notifier/<br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=15193<br />
*Screenshots: http://code.google.com/p/pacman-notifier/<br />
<br />
===pacupdate===<br />
<br />
Pacupdate is a small application that notifies the user about new updates for Arch Linux. If pacupdate finds out that a update is available, it will display a notification in SystemTray.<br />
<br />
*Homepage: http://code.google.com/p/pacupdate/<br />
*AUR Package Details: http://aur.archlinux.org/packages.php?ID=19068<br />
*Screenshots: <br />
<br />
===ZenMan===<br />
<br />
PacMan frontend (tray update notifier) for GTK/GNOME/zenity/libnotify.<br />
<br />
*Homepage:<br />
*AUR Package Details:http://aur.archlinux.org/packages.php?ID=25948<br />
*Screenshots:http://show.harvie.cz/screenshots/zenman-screenshot-2.png<br />
<br><br />
<br />
= Inactive Software Packages =<br />
*[http://guzuta.berlios.de/ Guzuta]<br />
*[https://opensvn.csie.org/PacmanManager/ PacmanManager]<br />
*[http://code.google.com/p/pacmon/ pacmon]<br />
*[https://gna.org/projects/paku/ Paku]<br />
*[http://www.kde-apps.org/content/show.php/YAPG+-+Yet+Another+Pacman+Gui+?content=60052 YAPG]<br />
*[http://sourceforge.net/projects/zenitypacgui/ zenity_pacgui]</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74935Enhance system stability2009-09-01T15:45:52Z<p>Lseubert: /* Avoid Certain Pacman Commands */ Tidied up for clarification</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. <br />
<br />
Only use AUR and 3rd party repositories if absolutely necessary. The AUR and various 3rd party repositories are not official Arch packages. Such packages may be buggy, or they may contain malicious code. Only use such packages on a stable system if absolutely necessary, and only after following precautions. See the section below on using [[Enhancing_Arch_Linux_Stability#Consider_Using_yaourt_to_Simplify_SysAdmin_Tasks| Using Yaourt to Simplify SysAdmin Tasks]] for more details.<br />
<br />
Avoid any use of the testing repository, or individual packages from testing. These experimental packages are for development and testing, and are not suitable for a stable system.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
This section is intentionally incomplete until the kernel26-lts package migrates out of testing. Those who wish to review the material that will be posted in this section, should click this section's "Edit" link to view the text blocks hidden by comment tags.<br />
<!--<br />
The kernel26-lts package is an alternative Arch kernel package based upon Linux kernel 2.6.27 and is available in the ?core/extra? repository. This particular kernel version enjoys long term support from upstream, including security fixes and some feature backports. Additionally, this package includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending upon which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. Instead, synchronize the pacman database and immediately install the new pacakge with the following commands:<br />
<br />
pacman -Syu && pacman -S Package-Name <br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips conflict checks. In a properly maintained system, it should never need to be used.<br />
<br />
Do not use ''pacman -Rd Package-Name''. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Use the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script] to move all but the last previously installed package versions in the pacman cache archives, to the home directory.<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74931Enhance system stability2009-09-01T15:01:14Z<p>Lseubert: /* Install the kernel26-lts Package */ tweak</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. <br />
<br />
Only use AUR and 3rd party repositories if absolutely necessary. The AUR and various 3rd party repositories are not official Arch packages. Such packages may be buggy, or they may contain malicious code. Only use such packages on a stable system if absolutely necessary, and only after following precautions. See the section below on using [[Enhancing_Arch_Linux_Stability#Consider_Using_yaourt_to_Simplify_SysAdmin_Tasks| Using Yaourt to Simplify SysAdmin Tasks]] for more details.<br />
<br />
Avoid any use of the testing repository, or individual packages from testing. These experimental packages are for development and testing, and are not suitable for a stable system.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
This section is intentionally incomplete until the kernel26-lts package migrates out of testing. Those who wish to review the material that will be posted in this section, should click this section's "Edit" link to view the text blocks hidden by comment tags.<br />
<!--<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the ?core/extra? respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending upon which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. Instead, synchronize the pacman database and immediately install the new pacakge with the following commands:<br />
<br />
pacman -Syu && pacman -S Package-Name <br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips conflict checks. In a properly maintained system, it should never need to be used.<br />
<br />
Do not use ''pacman -Rd Package-Name''. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74928Enhance system stability2009-09-01T14:36:53Z<p>Lseubert: /* Select the Core and Extra Software Repositories */ Strengthened warnings about AUR and testing</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. <br />
<br />
Only use AUR and 3rd party repositories if absolutely necessary. The AUR and various 3rd party repositories are not official Arch packages. Such packages may be buggy, or they may contain malicious code. Only use such packages on a stable system if absolutely necessary, and only after following precautions. See the section below on using [[Enhancing_Arch_Linux_Stability#Consider_Using_yaourt_to_Simplify_SysAdmin_Tasks| Using Yaourt to Simplify SysAdmin Tasks]] for more details.<br />
<br />
Avoid any use of the testing repository, or individual packages from testing. These experimental packages are for development and testing, and are not suitable for a stable system.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
This section is intentionally incomplete until the kernel26-lts package migrates out of testing. Those who wish to review the material that will be posted in this section, should click this section's "Edit" link to view the text blocks hidden by comment tags.<br />
<!--<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the ?core/extra? respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. Instead, synchronize the pacman database and immediately install the new pacakge with the following commands:<br />
<br />
pacman -Syu && pacman -S Package-Name <br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips conflict checks. In a properly maintained system, it should never need to be used.<br />
<br />
Do not use ''pacman -Rd Package-Name''. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74919Enhance system stability2009-09-01T13:25:33Z<p>Lseubert: /* Minimize the Number of Installed Packages */ Removed bit about not mixing GUI tookits</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
This section is intentionally incomplete until the kernel26-lts package migrates out of testing. Those who wish to review the material that will be posted in this section, should click this section's "Edit" link to view the text blocks hidden by comment tags.<br />
<!--<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the ?core/extra? respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. Instead, synchronize the pacman database and immediately install the new pacakge with the following commands:<br />
<br />
pacman -Syu && pacman -S Package-Name <br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips conflict checks. In a properly maintained system, it should never need to be used.<br />
<br />
Do not use ''pacman -Rd Package-Name''. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74916Enhance system stability2009-09-01T12:51:04Z<p>Lseubert: /* Revert Package Upgrades That Cause Instability */ Reverted to the method first suggested by Allan</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
This section is intentionally incomplete until the kernel26-lts package migrates out of testing. Those who wish to review the material that will be posted in this section, should click this section's "Edit" link to view the text blocks hidden by comment tags.<br />
<!--<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the ?core/extra? respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. Instead, synchronize the pacman database and immediately install the new pacakge with the following commands:<br />
<br />
pacman -Syu && pacman -S Package-Name <br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips conflict checks. In a properly maintained system, it should never need to be used.<br />
<br />
Do not use ''pacman -Rd Package-Name''. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74915Enhance system stability2009-09-01T12:48:28Z<p>Lseubert: /* Avoid Certain Pacman Commands */ Added warning about pacman -Rd</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
This section is intentionally incomplete until the kernel26-lts package migrates out of testing. Those who wish to review the material that will be posted in this section, should click this section's "Edit" link to view the text blocks hidden by comment tags.<br />
<!--<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the ?core/extra? respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. Instead, synchronize the pacman database and immediately install the new pacakge with the following commands:<br />
<br />
pacman -Syu && pacman -S Package-Name <br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips conflict checks. In a properly maintained system, it should never need to be used.<br />
<br />
Do not use ''pacman -Rd Package-Name''. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74888Enhance system stability2009-08-30T14:43:10Z<p>Lseubert: /* Install the kernel26-lts Package */ tweak</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
This section is intentionally incomplete until the kernel26-lts package migrates out of testing. Those who wish to review the material that will be posted in this section, should click this section's "Edit" link to view the text blocks hidden by comment tags.<br />
<!--<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the ?core/extra? respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. Instead, synchronize the pacman database and immediately install the new pacakge with the following commands:<br />
<br />
pacman -Syu && pacman -S Package-Name <br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips conflict checks. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74887Enhance system stability2009-08-30T14:41:16Z<p>Lseubert: Added notice about kernel26-lts</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the [[Improve_Pacman_Performance#Using_rankmirror|rankmirror]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install the kernel26-lts Package===<br />
<br />
This section is intentionally left blank until the kernel26-lts package migrates out of testing. Those who wish to review the material that will be posted in this section, should click this section's "Edit" link to view the text blocks hidden by comment tags.<br />
<!--<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. Instead, synchronize the pacman database and immediately install the new pacakge with the following commands:<br />
<br />
pacman -Syu && pacman -S Package-Name <br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips conflict checks. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=User:Lseubert&diff=74886User:Lseubert2009-08-30T14:01:17Z<p>Lseubert: /* Arch Wikipages that I have started: */</p>
<hr />
<div>=Arch Wiki Curriculum Vitae=<br />
<br />
===Arch Wikipages that I have started:===<br />
<br />
#[http://wiki.archlinux.org/index.php/Enhancing_Arch_Linux_Stability Enhancing Arch Linux Stability]<br />
#[http://wiki.archlinux.org/index.php/Open_ERP Open ERP]<br />
#[http://wiki.archlinux.org/index.php/History_of_Arch_Linux History of Arch Linux]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I am currently working on:===<br />
#[http://wiki.archlinux.org/index.php/Open_ERP Open ERP]<br />
#[http://wiki.archlinux.org/index.php/History_of_Arch_Linux History of Arch Linux]<br />
#Pending merger of: [http://wiki.archlinux.org/index.php/Community_Projects Community Project]; [http://wiki.archlinux.org/index.php/How_to_become_an_Arch_developer How to become an Arch developer]; and [http://wiki.archlinux.org/index.php/Mutualism_Arch Mutualism Arch]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have made major revisions to:===<br />
#[http://wiki.archlinux.org/index.php/Arch-based_Distros Arch-based Distros] The previous version [http://wiki.archlinux.org/index.php?title=Arch-based_Distros&oldid=69020 was this.]<br />
#[http://wiki.archlinux.org/index.php/Arch_Linux_Press_Review Arch Linux Press Review] The previous version [http://wiki.archlinux.org/index.php?title=Arch_Linux_Press_Review&oldid=52209 was this.]<br />
#[http://wiki.archlinux.org/index.php/Licenses Licenses] The previous version [http://wiki.archlinux.org/index.php?title=Licenses&oldid=31564 was this.]<br />
#[http://wiki.archlinux.org/index.php/AUR_Helpers AUR Helpers] The previous version [http://wiki.archlinux.org/index.php?title=AUR_Helpers&oldid=69391 was this.]<br />
#[http://wiki.archlinux.org/index.php/Pacman_GUI_Frontends Pacman GUI Frontends] The previous version [http://wiki.archlinux.org/index.php?title=Pacman_GUI_Frontends&oldid=70128 was this.]<br />
<br><br />
<br><br />
<br />
===Arch Wikipages that I have contributed to:===<br />
<br />
#[http://wiki.archlinux.org/index.php/Unofficial_user_repositories Unofficial user repositories]<br />
<br><br />
<br />
===Arch Wikipages that I have tweaked slightly:===<br />
#[http://wiki.archlinux.org/index.php/Community_Projects Community Projects]<br />
#[http://wiki.archlinux.org/index.php/How_to_become_an_Arch_developer How to become an Arch Developer]<br />
#[http://wiki.archlinux.org/index.php/Mutualism_Arch Mutualism Arch]<br />
#[http://wiki.archlinux.de/title/Arch_in_den_Medien Arch in den Medien]<br />
#[http://wiki.archlinux.org/index.php/Enlightenment Enlightenment]<br />
#[http://wiki.archlinux.org/index.php/ABS_-_The_Arch_Build_System ABS - The Arch Build System]<br />
#[http://wiki.archlinux.org/index.php/Makepkg Makepkg]<br />
<br><br />
<br />
===Arch Wikipages that I have helped to merge:===<br />
<br />
#In discussion - proposed but not yet completed merger of: [http://wiki.archlinux.org/index.php/Community_Projects Community Projects], [http://wiki.archlinux.org/index.php/How_to_become_an_Arch_developer How to become an Arch developer], and [http://wiki.archlinux.org/index.php/Mutualism_Arch Mutualism Arch].<br />
<br></div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74879Enhance system stability2009-08-30T00:01:22Z<p>Lseubert: /* Avoid Certain Pacman Commands */ Altered command</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. Instead, synchronize the pacman database and immediately install the new pacakge with the following commands:<br />
<br />
pacman -Syu && pacman -S Package-Name <br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips conflict checks. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed*<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74872Enhance system stability2009-08-29T22:20:43Z<p>Lseubert: /* Generic Best Practices */ Shifted 'Test Updates' section</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed*<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74871Enhance system stability2009-08-29T22:16:11Z<p>Lseubert: /* Regularly Backup the /home, /srv, and /var Directories */ tweak</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed*<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74870Enhance system stability2009-08-29T22:15:09Z<p>Lseubert: /* Always Backup Config Files Before Editing */ why use .bak info added</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed*<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
Using ''.bak'' will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74869Enhance system stability2009-08-29T22:11:12Z<p>Lseubert: /* Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert */ clarity tweak</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed*<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74866Enhance system stability2009-08-29T22:06:24Z<p>Lseubert: /* Regularly Backup a List of Installed Packages */ Revised the commands as suggested by Pat Brisban</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed*<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74863Enhance system stability2009-08-29T21:46:30Z<p>Lseubert: /* Regularly Purge Cruft */ clarity tweaks</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages, which it does as part of its routine use. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg, which have been permanently removed from the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74862Enhance system stability2009-08-29T21:40:07Z<p>Lseubert: /* Revert Package Upgrades That Cause Instability */ Added documentation link, clarified</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might also be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
If the package has dependencies, before installing the package; install the dependencies by name using the same command and archive as listed above. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the [[Pacman#Skip_upgrade_package| IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74861Enhance system stability2009-08-29T21:31:15Z<p>Lseubert: /* Avoid Certain Pacman Commands */ tweaks</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database:<br />
<br />
pacman -Sc<br />
<br />
Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.<br />
<br />
In the event that /var disk space becomes scarce, move '''all''' archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Move all but the last previously installed package versions in the pacman cache archives, to the home directory (this makes package reversion much easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74860Enhance system stability2009-08-29T20:57:40Z<p>Lseubert: /* Read Before Upgrading the System */ Added link to Arch webforums</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate [http://bbs.archlinux.org/ webforum] to see if there have been any reported problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74859Enhance system stability2009-08-29T20:55:40Z<p>Lseubert: /* Set IgnorePkg */ Added link to wiki</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades. Refer to the [[Pacman#Skip_upgrade_package| Skip upgrade package]] section of the Pacman Arch wikipage for further details.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74858Enhance system stability2009-08-29T20:52:09Z<p>Lseubert: /* Select the Core and Extra Software Repositories */ Added link to pacman arch wikipage</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the [[Pacman#Repositories| Repositories]] section of the Pacman Arch wikipage.<br />
<br />
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74857Enhance system stability2009-08-29T20:41:34Z<p>Lseubert: /* Minimize the Number of Installed Packages */ explained why</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean. The fewer the number of packages, and the simpler the selection of packages; the less chance of software bugs causing instability.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74856Enhance system stability2009-08-29T20:39:15Z<p>Lseubert: /* Consider Using yaourt to Simplify SysAdmin Tasks */ Clairifed prose.</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74855Enhance system stability2009-08-29T20:28:13Z<p>Lseubert: /* Avoid Development Packages */ tweaks</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special Arch kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74853Enhance system stability2009-08-29T20:19:00Z<p>Lseubert: /* Use Up to Date Mirrors */ Explained why. Slightly changes wikipage link.</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.<br />
<br />
Also, if it is used, edit the mirror list in /etc/pacman.d by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling_your_favorite_mirror| Enabling your favorite mirror]] Arch wikipage section for additional details, including the installation of the '''rankmirrors''' script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.<br />
<br />
After changing the server mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74852Enhance system stability2009-08-29T19:58:28Z<p>Lseubert: /* Use Recommended Configurations */ Clarified slightly</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74851Enhance system stability2009-08-29T19:55:25Z<p>Lseubert: /* Activate as Few Modules and Daemons in rc.conf as Possible */ Explained why and edited for clarity.</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
During the initial configuration of an Arch system, use the fewest number of services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. The fewer services running, the less chance of instability problems caused by buggy software or corner-case software conflicts.<br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74850Enhance system stability2009-08-29T19:48:19Z<p>Lseubert: /* Set Up a Large /var Partition and Keep Old Packages */ Explained why this is necessary</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 6 to 8 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space. Retaining these packages is helpful if a recent package upgrade causes instability, requiring a downgrade to an older, archived package. See the section below entitled, [[Enhancing_Arch_Linux_Stability#Revert_Package_Upgrades_That_Cause_Instability|Revert Package Upgrades That Cause Instability]].<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74849Enhance system stability2009-08-29T19:05:37Z<p>Lseubert: /* Set Up a Large /var Partition and Keep Old Packages */ Removed surplusage</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74848Enhance system stability2009-08-29T19:04:26Z<p>Lseubert: /* Never Use the Pacman --force Option */ Rewrote and renamed the entire section</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Avoid Certain Pacman Commands===<br />
<br />
Never use ''pacman -Sy Package-Name'' or ''pacman -Syy Package-Name'' to install a package. This could cause synchronization errors between the local pacman database, and the online mirror's pacman database. The result will be a tedious system repair. Instead, use one of the two following commands:<br />
<br />
pacman -S Package-Name<br />
pacman -Syu Package-Name<br />
<br />
Avoid using the '''-f''' option with pacman, for example, ''pacman -Syuf'' or ''pacman -Uf''. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
Never run ''pacman -Scc'' unless there is a desparate need for the disk space and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use the following command to clean out the entries in the pacman database of packages that were previously removed:<br />
<br />
pacman -Sc<br />
<br />
In the event that /var disk space becomes scarce, backup all archived packages to the home directory using the [http://www.3111skyline.com/download/Archlinux/scripts/fdup-archpkg fdup-archpkg script]. Backup all but the most recent duplicate packages (which makes package reversion easier), by using the [http://www.3111skyline.com/download/Archlinux/scripts/fduppkg fduppkg script].<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74846Enhance system stability2009-08-29T18:33:20Z<p>Lseubert: Moved stuff around, rewrote some material. More to come.</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Consider Using Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove the package and any of its dependencies, which might be part of the problem. This is done by executing the command:<br />
<br />
pacman -Rs Package-Name<br />
<br />
Then, install the last known stable version of the package from the local pacman cache using the following command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
A similar command will be required to first install any dependencies from from the local cache. For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrade packages]].<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhancing_Arch_Linux_Stability_HOWTO&diff=74843Enhancing Arch Linux Stability HOWTO2009-08-29T17:05:18Z<p>Lseubert: moved Enhancing Arch Linux Stability HOWTO to Enhancing Arch Linux Stability:&#32;There was a request to drop the HOWTO bit. A bit too much like Gentoo documentation I was told. This title is shorter and sweeter :-)</p>
<hr />
<div>#REDIRECT [[Enhancing Arch Linux Stability]]</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74842Enhance system stability2009-08-29T17:05:18Z<p>Lseubert: moved Enhancing Arch Linux Stability HOWTO to Enhancing Arch Linux Stability:&#32;There was a request to drop the HOWTO bit. A bit too much like Gentoo documentation I was told. This title is shorter and sweeter :-)</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74827Enhance system stability2009-08-29T05:31:42Z<p>Lseubert: /* Deal Promptly with .pacnew, .pacsave, and .pacorig Files */ Added pacdiff and pacnew info</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. <br />
<br />
There are various tools to help resolve .pacnew and .pacsave file issues. Yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues, offering an array of viewer/editor tools. The pacman-contrib package includes a tool, pacdiff, which helps to sort through such files. Finally, the [http://pbrisbin.com:8080/bin/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74826Enhance system stability2009-08-29T05:23:05Z<p>Lseubert: /* Regularly Backup the Pacman Database */ tweak</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals - possibly before each system upgrade, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74825Enhance system stability2009-08-29T04:48:41Z<p>Lseubert: /* Consider Using yaourt to Simplify SysAdmin Tasks */ Cut a sentence I wrote for improved paragraph cohesiveness</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted Bash scripts which may delete any file the user has write permissions to, by malicious design or accident. Anything you may do in your user's Bash shell, the AUR package installation could do. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74823Enhance system stability2009-08-29T03:56:13Z<p>Lseubert: /* Consider Using yaourt to Simplify SysAdmin Tasks */ tweak</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted bash scripts which may delete any file they have permissioned access to. Use yaourt for its handy SysAdmin functions, but be wary of using it for access to the AUR. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74822Enhance system stability2009-08-29T03:46:32Z<p>Lseubert: /* Install and Use yaourt */ Tightened up submitted material and detailed SysAdmin tasks</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Consider Using yaourt to Simplify SysAdmin Tasks===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions. <br />
<br />
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.<br />
<br />
Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potential serious security risks, as yaourt executes user-submitted bash scripts which may delete any file it has permissioned access to. Use yaourt for its handy SysAdmin functions, but be wary of using it for access to the AUR. Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74810Enhance system stability2009-08-28T21:15:57Z<p>Lseubert: Moved lts section</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
===Install and Use yaourt===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It also performs several routine but important SysAdmin tasks automatically. It uses the same command syntax as pacman, and usually invokes pacman to perform most functions. Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Use yaourt for its handy SysAdmin functions, but be wary of using it for access to the AUR.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74809Enhance system stability2009-08-28T20:48:31Z<p>Lseubert: /* Use Up to Date Mirrors */ tweak</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure that the mirror and local pacman databases are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install and Use yaourt===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It also performs several routine but important SysAdmin tasks automatically. It uses the same command syntax as pacman, and usually invokes pacman to perform most functions. Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Use yaourt for its handy SysAdmin functions, but be wary of using it for access to the AUR.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74808Enhance system stability2009-08-28T20:40:55Z<p>Lseubert: /* Introduction */ tweak</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure the mirror and local pacman database are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install and Use yaourt===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It also performs several routine but important SysAdmin tasks automatically. It uses the same command syntax as pacman, and usually invokes pacman to perform most functions. Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Use yaourt for its handy SysAdmin functions, but be wary of using it for access to the AUR.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74807Enhance system stability2009-08-28T20:34:14Z<p>Lseubert: Added warning about Yaourt. Updated unpublished kernel26-lts info.</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy an exceptionally stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure the mirror and local pacman database are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install and Use yaourt===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It also performs several routine but important SysAdmin tasks automatically. It uses the same command syntax as pacman, and usually invokes pacman to perform most functions. Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Use yaourt for its handy SysAdmin functions, but be wary of using it for access to the AUR.<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fix and some feature backports. Additionally, this package is specially configured for long term use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74704Enhance system stability2009-08-26T23:19:17Z<p>Lseubert: /* Revert Package Upgrades That Cause Instability */</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy an exceptionally stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure the mirror and local pacman database are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install and Use yaourt===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It also performs several routine but important SysAdmin tasks automatically. It uses the same command syntax as pacman, and usually invokes pacman to perform most functions. It also handles the management of AUR packages. Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27. This particular kernel version enjoys several years worth of support from a group of Linux kernel developers, including security fix backports. Additionally, this package is specially configured for long term use with Arch, and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed from the core/extra/community/testing repository, using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74703Enhance system stability2009-08-26T23:18:26Z<p>Lseubert: /* Revert Package Upgrades That Cause Instability */ Prepped a kernel26-lts section</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy an exceptionally stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure the mirror and local pacman database are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install and Use yaourt===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It also performs several routine but important SysAdmin tasks automatically. It uses the same command syntax as pacman, and usually invokes pacman to perform most functions. It also handles the management of AUR packages. Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
<!--<br />
===Install the kernel26-lts Package===<br />
<br />
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27. This particular kernel version enjoys several years worth of support from a group of Linux kernel developers, including security fix backports. Additionally, this package is specially configured for long term use with Arch, and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.<br />
<br />
More information about this kernel package may be found in this [http://bbs.archlinux.org/viewtopic.php?id=78784 Arch Forums thread]. The kernel may be installed from the core/extra/community/testing repository, using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.<br />
--><br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseuberthttps://wiki.archlinux.org/index.php?title=Enhance_system_stability&diff=74702Enhance system stability2009-08-26T22:49:32Z<p>Lseubert: /* Avoid Development Packages */ tweak</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
The purpose of this wiki article is to provide tips on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.<br />
<br />
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy an exceptionally stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.<br />
<br />
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.<br />
<br />
=Setting Up Arch=<br />
<br />
When first installing and configuring Arch Linux, the user has a variety of choices to make about configuration, software, and drivers. These choices will impact overall system stability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Set Up a Large /var Partition and Keep Old Packages===<br />
<br />
When setting up partitions during installation, always be sure to allocate plenty of space for a large, separate /var partition. A /var partition should have a generous 8 to 10 GB of space - more for some server uses. Pacman archives all of the previously installed packages in /var/cache/pacman/pkg, which requires significant amounts of storage space.<br />
<br />
Never run the pacman -Scc command! It will purge all of these archived packages, some of which might be required for future system repairs.<br />
<br />
===Activate as Few Modules and Daemons in rc.conf as Possible===<br />
<br />
When initially configuring an Arch system, use the fewest services possible. When editing the /etc/rc.conf file, only activate those modules and daemons that are absolutely necessary to run the system. <br />
<br />
===Use Recommended Configurations===<br />
<br />
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup|configure a login manager]] to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the [[Adding_a_login_manager_%28KDM,_GDM,_or_XDM%29_to_automatically_boot_on_startup#Inittab_Method_.28recommended.29|inittab method]]). The recommended, default configurations are the best choice for optimum system stability.<br />
<br />
===Select the Core and Extra Software Repositories===<br />
<br />
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.<br />
<br />
===Use Up to Date Mirrors===<br />
<br />
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [http://users.archlinux.de/~gerbra/mirrorcheck.html Arch Mirror Check webpage] to verify that your chosen mirror is up to date. Also, if used, edit the mirror list in /etc/pacman.d/ by placing local mirrors at the top of the list. Then, install the [[Mirrors#Sort_Your_Mirrors_by_Their_Speed|rankmirrors Python script]] and use it to enable the fastest local mirrors.<br />
<br />
When changing the mirror used for updates, to ensure the mirror and local pacman database are fully synchronized, always execute the following command:<br />
<br />
pacman -Syy<br />
<br />
===Avoid Development Packages===<br />
<br />
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, or darcs. <br />
<br />
Most especially - avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.<br />
<br />
If building a custom package using makepkg, be sure that the PKGBUILD follows the [[Arch Packaging Standards]], including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.<br />
<br />
===Install and Use yaourt===<br />
<br />
[http://archlinux.fr/yaourt-en Yaourt], which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It also performs several routine but important SysAdmin tasks automatically. It uses the same command syntax as pacman, and usually invokes pacman to perform most functions. It also handles the management of AUR packages. Information about installing yaourt is found on the [[yaourt|yaourt Arch wikipage]]. Detailed usage instructions are available through the command:<br />
<br />
yaourt -h<br />
<br />
==Generic Best Practices==<br />
<br />
===Minimize the Number of Installed Packages===<br />
<br />
Only install those software packages that are needed, and no more. For example, servers rarely require the installation and configuration of xorg and GUI software, so do not install them on server machines. Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.<br />
<br />
===Use Proven, Mainstream Software Packages===<br />
<br />
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.<br />
<br />
===Choose Open Source Drivers===<br />
<br />
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at [http://www.linux-drivers.org/ linux-drivers.org].<br />
<br />
=Maintaining Arch=<br />
<br />
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.<br />
<br />
==Arch Specific Tips==<br />
<br />
===Upgrade Entire System with Reasonable Frequency===<br />
<br />
Many Arch users update frequently, even upgrading their systems daily using pacman -Syu. While updating so frequently is not necessary, one should upgrade fairly often to enjoy the latest bugfix and security updates. Weekly or biweekly upgrades are thus a good idea.<br />
<br />
If the system has packages from the AUR, upgrade all AUR packages with the following command: <br />
<br />
yaourt -Syu --aur<br />
<br />
Be aware that such an update can take considerably more time than a normal system upgrade invoked by using pacman -Syu or yaourt -Syu.<br />
<br />
===Set IgnorePkg===<br />
<br />
In the /etc/pacman.conf file, there is a section for listing packages to be ignored during upgrades. Uncomment the IgnorePkg line, and list the packages that should not be changed during upgrades.<br />
<br />
For example, when a new major kernel release comes out, such as 2.6.30.0, one might want to wait until the first point release, 2.6.30.1, before upgrading the kernel. In such a case, edit the pacman.conf file so that the IgnorePkg line reads as follows (be sure to include any necessary firmware kernel modules): <br />
<br />
IgnorePkg = kernel26 kernel26-firmware<br />
<br />
With proprietary video drivers, one might want to hold back updating the driver itself, as well as the kernel and xorg-server packages, until a new video driver compatible with the latest kernel and xorg-server packages is available.<br />
<br />
===Read Before Upgrading the System===<br />
<br />
Before upgrading Arch, always read the latest [http://www.archlinux.org/news/ Arch News] to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software, such as the kernel, xorg, or glibc to a new version; look over the appropriate webforum to see if there have been any recent problems.<br />
<br />
===Act on Alerts During an Upgrade===<br />
<br />
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.<br />
<br />
===Deal Promptly with .pacnew, .pacsave, and .pacorig Files===<br />
<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
Users must deal with these files when pacman creates them, in order to ensure optimum system stability. Users are referred to the [[Pacnew and Pacsave Files]] wiki page for detailed instructions. Additionally, yaourt provides a CLI program, pacdiffviewer, which assists with the proper resolution of .pacnew and .pacsave issues.<br />
<br />
===Use Pacmatic===<br />
<br />
[http://kmkeen.com/pacmatic/index.html Pacmatic] is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. Pacmatic is available [http://aur.archlinux.org/packages.php?ID=29541 from the AUR]. To use pacmatic with yaourt, edit the /etc/yaourtrc file so that the PacmanBin line reads:<br />
<br />
PacmanBin /usr/bin/pacmatic<br />
<br />
===Revert Package Upgrades That Cause Instability===<br />
<br />
In the event that a particular package upgrade results in system instability, remove it with the following command:<br />
<br />
pacman -R Package-Name<br />
<br />
Then revert to the last known stable version of that package. This is done by executing the command:<br />
<br />
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz<br />
<br />
Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.<br />
<br />
===Never Use the Pacman --force Option===<br />
<br />
Avoid using the '''-f''' option with pacman, for example, pacman -Syuf or pacman -Uf. The --force option skips dependency and conflict checks and overwrites installed configuration files. In a properly maintained system, it should never need to be used.<br />
<br />
===Regularly Purge Cruft===<br />
<br />
At regular intervals, review the activated modules and daemons in the /etc/rc.conf file, and remove those that are no longer needed. <br />
<br />
Use the yaourt package manager to safely and automatically remove orphan packages. With pacman, find and remove orphan packages no longer used as dependencies as follows:<br />
<br />
sudo pacman -Rs $(pacman -Qtdq)<br />
<br />
Use caution - this is a powerful command that can damage the system if improperly used.<br />
<br />
Run the following command to clean out archived packages from /var/cache/pacman/pkg which are no longer installed on the system:<br />
<br />
pacman -Sc<br />
<br />
To optimize the pacman database for best speed, run the command:<br />
<br />
pacman-optimize && sync<br />
<br />
===Regularly Backup a List of Installed Packages===<br />
<br />
At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:<br />
<br />
pacman -Qqe | grep -v "$(pacman -Qmq)" > /path/to/chosen/directory/pkglist<br />
<br />
In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:<br />
<br />
pacman -S $(cat pkglist)<br />
<br />
===Regularly Backup the Pacman Database===<br />
<br />
At regular intervals, using yaourt, execute the following command to backup the local pacman database:<br />
<br />
yaourt -B /path/to/chosen/directory/<br />
<br />
Yaourt can be used to restore the backup pacman database file with the following command:<br />
<br />
yaourt -B /path/to/chosen/directory/Name-of-Backup-File.tar.bz2<br />
<br />
The following command will accomplish the same task, and can be run as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local<br />
<br />
Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.<br />
<br />
Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the /var/lib/pacman directory and executing the following command:<br />
<br />
tar -xjvf pacman-database.tar.bz2<br />
<br />
If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, [[How_To_Restore_Pacman's_Local_Database|How To Restore Pacman's Local Database]].<br />
<br />
===Regularly Upgrade Pacman===<br />
<br />
By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components. To ensure that the latest version of pacman is installed on your system, execute the command:<br />
<br />
pacman -Sy pacman<br />
<br />
==Generic Best Practices==<br />
<br />
===Subscribe to NVD/CVE Alerts and Only Upgrade On a Security Alert===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm| NVD Download webpage]. Only update the Arch system when a security alert is issued for a package installed on that particular system.<br />
<br />
This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed packages can be time consuming.<br />
<br />
===Always Backup Config Files Before Editing===<br />
<br />
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:<br />
<br />
cp Config-File Config-File.bak<br />
<br />
===Regularly Backup the /home, /srv, and /var Directories===<br />
<br />
At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Server installations should have the /srv directory regularly backed up. There may be additional directories in /var, such a /var/spool/mail or /var/lib which also require backup and occasional verification.<br />
<br />
===Regularly Backup the /etc Directory===<br />
<br />
At regular intervals, backup the /etc directory by executing the following command as root or as a cronjob:<br />
<br />
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc<br />
<br />
Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.<br />
<br />
Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:<br />
<br />
tar -xvjf etc-backup.tar.bz2<br />
<br />
===Test Updates On A Non-Critical System===<br />
<br />
If possible, test changes to configuration files as well as updates to software packages on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.</div>Lseubert