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@xxxxxxxxxxxxxxx> 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
