Thank guys for the reply! On Fri, Mar 7, 2014 at 3:49 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

If you take a look at https://www.archlinux.org/ you'll be informed about what you need to do, if there should be something to do. There might be an arch website in your native language too. I use https://www.archlinux.de/ as my web browser's startpage.

-- Ing. Ary Kleinerman Building Networks S.A. Córdoba, Argentina +54 351 5544150

On Sat, Mar 08, 2014 at 10:40:27AM -0600, Stephen Martin wrote:

If you want to use arch in a server environment, you should probably use your own repo to be safe.

Have a testing machine be on rolling release. When that machine is stable, push its packages to a private repo and update your server via the private repo.

That is, IMNSHO, a terribly sensible idea for reliable running of critical installations, and I've been implementing this procedure for a while now with good results: Manually, with a lot of pacman ad-hackery. :P I have yet to find some "glue" to make this easier and more fool proof for production usage. Is it possible that really no-one has yet created a script or Makefile or anything to automate the process of: 1) Updating a running test installation, including AUR and custom packages, to a specific point in time (most often: now) 1a) Alternative/Prerequisite to 1): Create a testing repository containing exactly those packages present after an update of a (hypothetical) testing system, i.e. a given set of packages. 2) Snapshotting the package state of a given running installation (or offline root), including AUR and custom packages 3) Synchronizing a specific custom repository to this exact package state determined in 2), without losing the custom and AUR packages on the way, and without keeping old/replaced packages around needlessly. Doing this is easy, superficially, but *practically* there are a few pitfalls involved, which kept me from just hacking up some scripts "real quickly" myself, dooming me to a life of repeating error-prone steps manually. Does anyone know of an existing and reliable solution to this administrative problem, or is this something to contribute back one day? Thanks, Dennis -- "Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen." Dr. Wolfgang Schäuble, Bundesinnenminister (14.10.08, TAZ-Interview) 0D21BE6C - F3DC D064 BB88 5162 56BE 730F 5471 3881 0D21 BE6C

On Monday 10 Mar 2014 10:08:06 yaro@marupa.net wrote:

I love Arch, but not for servers. I prefer Debian on my server. Despite all the dire warnings given to keep an eye on Arch's web site about certain upgrades, its still all too frequent user intervention is necessary where nothing is stated on the website at all about potential problems of that particular upgrade.

Oh yeah, you need to have your head screwed on for each update. That is certainly a bad thing if you just want a simple Samba or PHP web server, for instance.

Production environments do not need that sort of support. While latest and greatest and the newest features might sound great for the desktop, on servers it's not that critical, and long term support and a need for a release to "stand still" is much more important.

It depends on the usecase. For me, I rely on the ease with which I can modify and rebuild packages on Arch. There's a relatively complex interaction on this server, and I like to know that I'm in control. For instance, the Ruby rmagick gem doesn't like the imagemagick package that Arch ships, so I have to do a small tweak to the PKGBUILD and build it myself. I don't get that kind of flexibility with Debian. (I'm sure it's technically possible, but Debian isn't geared toward that workflow like Arch is.)

This is why I prefer Debian on my server: The only updates I should want on a server are those that improve the integrity and stability of its environment. I'll happily wait 2-3 years before I go for the major upgrades that will change the environment. Even then I might wait for "oldstable" to hit its EOL before upgrading, because not getting support at all is even worse.

At that point I can be confident that most of the upgrades won't need my intervention to work, save for a few things, thanks to testing.

For a straight-forward server that I want to set up and forget, I totally agree. For a server that I use for continuous development of internal tools, I think I'd find Debian too brittle.

Arch is great for power desktop users and those who want to be assured that they don't have to wait for months to years to get the latest Firefox or KDE/GNOME versions. But I've used it on servers juuuust enough to know it's not really suitable for that role.

I'd be using 3-year-old versions of Nginx, Redis, and Ruby if my server were Debian. As a developer, that's a real drag. It's just a different set of requirements, I think. Paul

On Monday 10 Mar 2014 15:40:13 John WH Smith wrote:

By the way, I strongly believe you will fix things faster if you like your environment (I assume it is Arch here, of course). Being used to your system is much more important than its stability when it comes to your sysadmin speed of reaction.

Yes, that is some top-quality wisdom right there. Paul

I'm thinking to use Arch for an Asterisk server. Nowadays I'm using Ubuntu 12.04LTS, but I can see all distribution changing to the new init system (systemd). I wanna change all my scripts to be compatible with systemd. Furthermore, my services use MySQL, so I think it's a good moment to migrate them to MariaDB. In short, I'll use Arch but I'll have a virtual server (for testing purposes) to make change there and then if all go okay, I'll apply the updates to the production environment. On Mon, Mar 10, 2014 at 12:40 PM, John WH Smith <jwhsmith@englandmail.com> wrote:

On 07/03/14 18:09, Ary Kleinerman wrote:

...

Hi, I'm a new Archer and I'm planning to install arch linux in a production server environment, but I have doubts because Arch is a rolling release. My question is: what does it happen when there are big changes? e.g. changes in the filesystem or when Arch has started using systemd. Regards, Ary

Hi,

As far as the rolling release is concerned, I don't think it should be banned just because the servers are production ones. To be honest, I think the problem goes a little deeper than that, and as it so happens, I ran into a similar questioning recently.

I think there are two important questions to ask : - Is the server set up for final users or actual programmers/technical folks ? - Does the server require maximal uptime, and how much downtime can it afford to take ?

For the first one, that's what finally brought me back to Debian on my latest install, even though I had absolutely no technical issue with using Arch. You see, I work with web developers on this machine, and they need an nginx server with PHP and MySQL available for their applications. To me, that is the tricky thing : these developers would assassinate me if I kept updating PHP regularly, because their local development environment doesn't have the same update rhythm, meaning I would probably take down their applications very often, because they cannot handle versions of PHP higher than theirs. Pretty logical actually, especially with Windows-based developers, who need to do a lot more manipulations to keep their WAMP install up-to-date (when they can). Same thing happens with other applications, even though I can't quote many more right now. Anyway, the question reveals an important point when you work with programmers : make sure you match development and production environments as much as you can (and it *does* require a lot of efforts if one of them is Arch).

Now, if your server aims at final users, like students (out of the computing field) or administratives, then I don't see many risks to anticipate. Applications do not rely on each other very much, crashing one doesn't mean taking the whole thing down. A failed update could be fixed without too much services downtime required.

The other question on the other hand remains quite obvious. If your server runs a simple Intranet in a company, where documents can still be shared physically in last resort, well : install Arch and enjoy the ride! The information system can afford longer downtimes, giving you enough time to fix whatever update messed things up. By the way, I strongly believe you will fix things faster if you like your environment (I assume it is Arch here, of course). Being used to your system is much more important than its stability when it comes to your sysadmin speed of reaction.

All in all : think about who uses (and messes with) your server, and how much they rely on it. To me, those are two important things to take into account when choosing your distribution.

-- Ing. Ary Kleinerman Building Networks S.A. Córdoba, Argentina +54 351 5544150