[renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

lseubert · 2009-08-22 03:58:37

Over in the 'Newbie Corner' webforum, a fairly active thread emerged, entitled, Does anyone really have a "rock stable" Arch?

In response to this thread, I have put together some material for a new wikipage, Enhancing Arch Linux Stability.

Right now, the tips are fairly basic, but they have worked well to ensure that my own system is stable and reliable. No doubt though, this wikipage would benefit from additional community input. Please share your stability tips by updating the wiki, so that everyone might enjoy a stable Arch experience. Thank you.

P.S. I don't want to be an alarmist here or anything folks, but really - let's get that wikipage into proper shape! There are heretics and blasphemers in that thread talking crazy talk about ditching Arch and installing Slackware, FreeBSD, Scientific Linux, or Debian. Please help guide them back onto the path of Arch Righteousness

P.S.S. Wikipage renamed to Enhancing Arch Linux Stability

Last edited by lseubert (2009-08-29 22:33:00)

&#32 Greg · 2009-08-22 04:02:42

It would be cool if there was a way to hold back all new updates say a week after they get released, and also a way to only grab security updates for those who want a stable system. Good article, though.

Last edited by &#32 Greg (2009-08-22 04:03:41)

lseubert · 2009-08-22 15:42:28

Greg wrote:

It would be cool if there was a way to hold back all new updates say a week after they get released, and also a way to only grab security updates for those who want a stable system. Good article, though.

I don't know if it is possible to only grab security updates. Arch does not have a Security Team which releases new software based on a security fix - Arch developers simply release the latest stable version from upstream, which is presumed to include the latest security fixes. Rolling release makes the conventional Linux distro security updating process moot.

Furthermore, oftentimes regular bug fixes are not separated from critical security fixes, but are bundled together by upstream. For example, the latest Linux kernel, 2.6.30.5, has a very important security fix update from 2.6.30.4, along with a bunch of regular, small bug fixes.

As for delaying package installation for a week, I can think of one quick and dirty way to do this off the top of my head. Set up a cron job which uses pacman -Syw to regularly download but not install software packages. Then, run a small bash script which invokes pacman to install any package in /var/cache/pacman/pkg/ that is more than one week old. Run the bash script whenever you are satisfied that the one week+ old packages are ready for your system.

Mr.Elendig · 2009-08-22 15:57:11

Greg wrote:

It would be cool if there was a way to hold back all new updates say a week after they get released, and also a way to only grab security updates for those who want a stable system. Good article, though.

There have been alteast 10 attemps to create a arch-stable repo/fork thingy, that only has security updateds and so on, but everyone have given up when they realized just how much work it would take.

(not to mention that you could just as well use debian instead)

A better solution imo, is to run a test box and a local repo. Test the updated on the test box first, and only push them to you local repo when you are somewhat sure that it won't blow up and destroy the world.

Last edited by Mr.Elendig (2009-08-22 15:58:30)

jcolinzheng · 2009-08-22 16:47:59

The test box solution above won't work well, thanks to the DLL dependency hell. (Consider, eg, the latest rock-solid version of Program X is 3.0, but it is linked against a non rock-solid version of Library Y. Such is common for Arch.)

Rock stable Arch is plain oxymoron. If you like rock stable you shoudl opt for Slackware, Debian or CRUX.

Last edited by jcolinzheng (2009-08-22 16:50:26)

keenerd · 2009-08-22 16:50:23

Also, there are various apps which automate some of the stable Arch tedium.

Here's mine: pacmatic

edit: Anonymo beat me by a minute! Arg!

Last edited by keenerd (2009-08-22 17:50:27)

Anonymo · 2009-08-22 17:46:13

keenerd wrote:

Also, there are various apps which automate some of the stable Arch tedium.
Here's mine: pacmann

http://aur.archlinux.org/packages.php?ID=29541

lseubert · 2009-08-22 21:00:43

keenerd wrote:

Also, there are various apps which automate some of the stable Arch tedium.
Here's mine: pacmatic
edit: Anonymo beat me by a minute! Arg!

I added an entry to the wikipage for pacmatic, keenard. Please take a look and see if the entry is correct.

What is the difference between 'pacmatic' and 'pacmann'? Should I list one or the other on the wikipage, or both? Thanks.

Also, steering this thread back to its original topic, if anybody else has ideas to contribute on how to configure and maintain Arch so that it is as stable as possible, please post them to the Rock Stable Arch Linux HOWTO wikipage.

keenerd · 2009-08-22 21:26:54

They are the same app. Pacmann is the old name, Pacmatic is the good name. Users can not delete their own packages from the AUR, otherwise it would be gone.

The bit comparing it to IgnorePkg is not exactly correct. It warns you about using stale repositories, and suggests you -Su when things get out of sync. More on its web page.

lseubert · 2009-08-22 23:32:18

keenerd wrote:

They are the same app. Pacmann is the old name, Pacmatic is the good name. Users can not delete their own packages from the AUR, otherwise it would be gone.
The bit comparing it to IgnorePkg is not exactly correct. It warns you about using stale repositories, and suggests you -Su when things get out of sync. More on its web page.

OK, thanks for the clarification. I cleaned up the Pacmatic section on the wikipage. Hopefully it is correct now.

Mr.Elendig · 2009-08-23 00:21:08

keenerd wrote:

They are the same app. Pacmann is the old name, Pacmatic is the good name. Users can not delete their own packages from the AUR, otherwise it would be gone.
The bit comparing it to IgnorePkg is not exactly correct. It warns you about using stale repositories, and suggests you -Su when things get out of sync. More on its web page.

You can request the package to be deleted on the aur-general mailing list.

keenerd · 2009-08-23 01:55:56

Mr.Elendig wrote:

You can request the package to be deleted on the aur-general mailing list.

I did, about eight hours ago. Still waiting.

lilsirecho · 2009-08-23 02:49:42

Rock stable archlinux requires a live usb install using tmpfs for ram enabled system performance.

This ensures rock-stable performance at the highest speed possible from the computer.

The upgrade to such a system could possibly be made every three months or so.

That would make a near-to-ideal arrangement but not----bleeding edge.

Advantage is apparent since a simple reboot restores the system. Since it is not able to retain data, storage with flash devices is probable.

Added versatility could be provided by having packages stored in read-only sources for install at users discretion. These packages could be provided as an overlay and run entirely in ram.

Thus, the intitial install could be minimum, possible providing faster boot into a minimal DE...say internet and e-mail. Scripts could then be used to install desired packages with depends. Since it is running in ram, speed isn't a problem.

Such a stable system would extend the initial success of Faunos, for example. This system used parts of Larch's arrangements to good measure.

Just a few comments on the subject of stable systems............

bangkok_manouel · 2009-08-23 14:59:21

In response to this thread, I have put together some material for a new wikipage, Rock Stable Arch Linux HOWTO.

Seriously guys, while the effort is very much appreciated (I really mean it), we moved form "Arch will not hold your hand" to "Arch is 5-years-old-friendly"...

lseubert · 2009-08-23 17:17:37

bangkok_manouel wrote:

In response to this thread, I have put together some material for a new wikipage, Rock Stable Arch Linux HOWTO.
Seriously guys, while the effort is very much appreciated (I really mean it), we moved form "Arch will not hold your hand" to "Arch is 5-years-old-friendly"...

High quality documentation is one of the prime hallmarks of operating system excellence. Without such documentation, ordinary users can not read and learn and do, thereby becoming proficient. To be sure, uber-users do not need documentation - but not everybody has a CompSci degree and 10 years of Unix SysAdmin experience. (And I bet that once in a while - when nobody is around and the lights are turned off - even uber-users read manpages. ) And while Arch documentation is nowadays quite detailed and 'easy', Arch remains well beyond the capabilities of most computer users, that is, computer neophytes.

Furthermore, the Rock Stable Arch Linux HOWTO is fully in keeping with "The Arch Way" principle of Freedom, which includes the freedom to make your Arch system into anything you want it to be. A number of Arch users would like their system to be stable, even with rolling release. And now these users have some documentation to guide them along.

I hope that experienced users, such as yourself bankok_manouel, will share their hard-won, collective wisdom on how to configure and maintain a stable Arch system, so that the entire Arch community may benefit.

Go on... edit the page. You know you want to.

Nepherte · 2009-08-23 18:05:07

Even experienced users consult documention. It may not be the arch wik but rather manpages or something elsei, but it's still documentation. I sincerely hope you're not disencouraged.

lseubert · 2009-08-23 21:02:13

Nepherte wrote:

Even experienced users consult documention. It may not be the arch wik but rather manpages or something elsei, but it's still documentation.

Yup. Good documentation is essential, no matter what form it takes.

Nepherte wrote:

I sincerely hope you're not disencouraged.

Heh. Oh, don't worry about me - my ego is quite a bit more bulletproof than that

I firmly and politely made my point in the post above, and I take no offense. I can sort of understand bangkok_manouel's PoV. My understanding of Arch history is that at one time, Arch wasn't especially well documented, and thus the domain of only truly proficient users. In recent years, apparently a lot of Gentoo and Ubuntu users have joined the Arch community, with a resulting explosion of detailed documentation on the Arch wiki. This has brought in even more new users, and the Arch community has changed slightly as a result. So I can see where bangkok is coming from.

Me? I just work on writing docs for the time being.

lseubert · 2009-08-26 04:17:16

Upon the advice of TomK, I have changed the name of the aforementioned wikipage to the new and improved, Enhancing Arch Linux Stability HOWTO.

Additionally, I have added a lot of material to the page over the past few days, and reorganized the content as well. If you are interested in running especially stable Arch systems, please read over the page. If you have any corrections or additional suggestions, please edit the page as you see fit.

In addition to lots of tips on configuring and maintaining a stable Arch system, there is also good advice on setting things up so as to make recovery from serious fubars fairly quick and painless. Mostly basic SysAdmin best practices.

Thanks,
Luke Seubert

fukawi2 · 2009-08-26 05:49:51

The -lts kernel should be good for this
http://bbs.archlinux.org/viewtopic.php?id=78784

Ranguvar · 2009-08-26 06:19:13

I'm tempted to change the section recommending Yaourt to say to NEVER use Yaourt What do you think?

Yaourt, in the process of installing AUR packages, automatically runs possibly malicious or accidently dangerous code in the PKGBUILDs and install scripts. Especially if we're advocating very few AUR packages for when stability is a concern, Yaourt shouldn't be needed. Instead, tools like pbget can grab the source (the --upgradable function will get new packages), and makepkg can create the packages. We should also advise thoroughly examining the build files before running makepkg.

bernarcher · 2009-08-26 07:34:57

Ranguvar wrote:

I'm tempted to change the section recommending Yaourt to say to NEVER use Yaourt What do you think?
Yaourt, in the process of installing AUR packages, automatically runs possibly malicious or accidently dangerous code in the PKGBUILDs and install scripts. Especially if we're advocating very few AUR packages for when stability is a concern, Yaourt shouldn't be needed. Instead, tools like pbget can grab the source (the --upgradable function will get new packages), and makepkg can create the packages. We should also advise thoroughly examining the build files before running makepkg.

While I share your concerns, I still have to find yaourt to automatically run PKBUILDs. I was always prompted to check the PKBUILD and afterwards to confirm the installation. Maybe I am wrong here, but if you remain on alert, cerefully checking the build/install, these processes are (almost) analogous to manually load, makepg, install procedures.

So, with possible yaourt problems explicitely stated, I think "NEVER use yaourt" would be some kind of overkill.

Almost forgot:
I use yaourt not for its semi-automatic AUR install capabilities but because it is a convenient way to search the AUR.

Last edited by bernarcher (2009-08-26 07:45:30)

lseubert · 2009-08-26 14:16:42

Ranguvar wrote:

I'm tempted to change the section recommending Yaourt to say to NEVER use Yaourt What do you think?

Oooh, ooh, ooh - you do that, and the flammage.... ooh, the flammage will burn down the arch server

Heh. Seriously, if you can demonstrate how yaourt in and of itself presents some serious problems, I'll be happy to revise that section. However, yaourt brings some good benefits, even for those who don't use the AUR.

Yaourt, in the process of installing AUR packages, automatically runs possibly malicious or accidently dangerous code in the PKGBUILDs and install scripts.

yaourt does provide a standard warning about installing AUR packages, and the risks they represent. And it always offers the option to view the PKGBUILD and install scripts in your favorite text editor, unless you turn that function off.

Especially if we're advocating very few AUR packages for when stability is a concern, Yaourt shouldn't be needed.

I somewhat agree - ideally, a really stable Arch system should avoid AUR packages. However, sometimes an AUR package is necessary. Arch isn't Debian, with its 27,000 packages and all Quick example - right now, Drupal is in community, while Joomla is in AUR.

Furthermore, yaourt provides some other services which are very useful for SysAdmin tasks, even if one doesn't use AUR. If a package is removed, resulting in orphan dependency packages, yaourt alerts the user and offers the option to remove them. Yaourt also provides an easy way to make snapshot backups of the local pacman database. Yaourt provides pacdiffviewer, which greatly helps in dealing with .pacsave and .pacnew files. Finally, it has a neat little --stats function, which spits back some interesting data.

Anyway, think if over and let me know. If the yaourt risks outweigh the benefits, I'll revise accordingly. Thanks.

P.S. Oh, and I forgot - yaourt also offers the option to run namcap against newly compiled AUR packages. Another useful SysAdmin feature.

Last edited by lseubert (2009-08-26 14:20:13)

lseubert · 2009-08-26 14:54:05

fukawi2 wrote:

The -lts kernel should be good for this
http://bbs.archlinux.org/viewtopic.php?id=78784

Many thanks for that tip. I'll write it up and add it in. Pity about the lack of ext4 support though

Nepherte · 2009-08-26 19:14:05

Ext4 support should be added now.

lseubert · 2009-08-26 20:27:31

Nepherte wrote:

Ext4 support should be added now.

Yeah, I saw it posted on that thread. However, it hasn't been tested thoroughly yet. I prefer to ensure that kernel26-lts has full ext4 support, or not - definitively, before posting about it on the wikipage. I hope it does get sorted out, because it is a great idea in a lot of ways.

Arch Linux

#1 2009-08-22 03:58:37

[renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#2 2009-08-22 04:02:42

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#3 2009-08-22 15:42:28

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#4 2009-08-22 15:57:11

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#5 2009-08-22 16:47:59

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#6 2009-08-22 16:50:23

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#7 2009-08-22 17:46:13

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#8 2009-08-22 21:00:43

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#9 2009-08-22 21:26:54

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#10 2009-08-22 23:32:18

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#11 2009-08-23 00:21:08

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#12 2009-08-23 01:55:56

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#13 2009-08-23 02:49:42

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#14 2009-08-23 14:59:21

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#15 2009-08-23 17:17:37

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#16 2009-08-23 18:05:07

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#17 2009-08-23 21:02:13

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#18 2009-08-26 04:17:16

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#19 2009-08-26 05:49:51

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#20 2009-08-26 06:19:13

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#21 2009-08-26 07:34:57

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#22 2009-08-26 14:16:42

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#23 2009-08-26 14:54:05

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#24 2009-08-26 19:14:05

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#25 2009-08-26 20:27:31

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

Board footer