Re: [arch-general] doubts about rolling release
On Wednesday 12 Mar 2014 15:21:23 Ary Kleinerman wrote: 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. This will work fine so long as you're aware that you can't install an Arch system and then forget about it for a few months. You have to update it every couple of weeks, at least. It needs more regular care than Ubuntu, or you could make things hard to yourself when you do come to update it. FYI, I think MariaDB is a drop-in replacement. Even the tools still use the mysql name; e.g. mysql_upgrade. You probably don't need to do anything special in your scripts. Paul
Re: [arch-general] doubts about rolling release
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 jwhsm...@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
Re: [arch-general] doubts about rolling release
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
Re: [arch-general] doubts about rolling release
On Friday 07 Mar 2014 15:09:27 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 I use Arch in production for several of our company's internal tools (bug tracker, SVN, etc...) I went through the systemd and /usr transition without a hiccup. The only downtime was the required reboot, I think. That's because I had been through the transition on my own machine and was well prepared. I've rarely had any issues caused by Arch updates. You do need to be aware of what packages to hold back (IgnorePkg in /etc/pacman.conf), which will depend on what you're using the server for. Finally, be sure to use a monitoring system. I use monit and ganglia. Together, they help me keep an eye on things like disk usage trends, and notify me of various causes for concern. I use rsnapshot for local iterative backup, along with a custom script that moves an archive onto a remote server that deals with getting it onto tape. (IT is all Windows-based; I'm pretty much the only Linux guy.) Paul
Re: [arch-general] doubts about rolling release
On Monday, March 10, 2014 10:13:39 AM Paul Gideon Dann wrote: On Friday 07 Mar 2014 15:09:27 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 I use Arch in production for several of our company's internal tools (bug tracker, SVN, etc...) I went through the systemd and /usr transition without a hiccup. The only downtime was the required reboot, I think. That's because I had been through the transition on my own machine and was well prepared. I've rarely had any issues caused by Arch updates. You do need to be aware of what packages to hold back (IgnorePkg in /etc/pacman.conf), which will depend on what you're using the server for. Finally, be sure to use a monitoring system. I use monit and ganglia. Together, they help me keep an eye on things like disk usage trends, and notify me of various causes for concern. I use rsnapshot for local iterative backup, along with a custom script that moves an archive onto a remote server that deals with getting it onto tape. (IT is all Windows-based; I'm pretty much the only Linux guy.) Paul I love Arch on the desktop. It's great for having new versions. On discrete release distributions if you hear a neat new feature of a program you use coming out you'll often find yourself waiting months, or maybe even years before it'll come down official channels. While I admit this assures the new feature will get plenty of testing and real world usage before you get it, it still sucks before you get a taste of the new feature. 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. 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. 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. 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 jst enough to know it's not really suitable for that role. Conrad
Re: [arch-general] doubts about rolling release
On Monday 10 Mar 2014 10:08:06 y...@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 jst 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
Re: [arch-general] doubts about rolling release
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.
Re: [arch-general] doubts about rolling release
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
Re: [arch-general] doubts about rolling release
On 10 March 2014 16:14:07 GMT, Paul Gideon Dann pdgid...@gmail.com wrote: 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. Please note: that wasn't intended as sarcasm: I actually agree that the admin's familiarity and happiness with the system is an important factor in maintenance and uptime. I was a little hasty to comment and may have been ambiguous. Sorry about that, Paul
Re: [arch-general] doubts about rolling release
On Fri, Mar 07, 2014 at 07:49:06PM +0100, Ralf Mardorf 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. Subscribing to arch-announce[1] is a very convenient way keep track of that. /M [1]: https://mailman.archlinux.org/mailman/listinfo/arch-announce -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgp7u_sFJ0YMN.pgp Description: PGP signature
Re: [arch-general] doubts about rolling release
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. Thank guys for the reply! On Fri, Mar 7, 2014 at 3:49 PM, Ralf Mardorf ralf.mard...@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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] doubts about rolling release
Hello, and welcome to the arch side! The transitions are made so that if you update often enough and do as the postinstall scripts and main page tell you to, then the transition goes easily. Both the systemd and moving to /usr/bin were done almost automatically (systemd had initscripts support for about a year, now still there as an option), the other also did have a few-minutes solution to most problems. However, there are some packages for which support is weak, usually for other major distributions not having them adopted yet, eg. bluez 5 was unusable for about half a year, now Apache 2.4 seems to be the same way, but these are supported by keeping the old versions in a separate, but compatible package (eg. bluez4, gtk2). --Oliver Temlin On Mar 7, 2014 7:09 PM, Ary Kleinerman akleiner...@buinet.com.ar 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 -- *Ing. Ary Kleinerman* Building Networks S.A. Córdoba, Argentina +54 351 5544150
Re: [arch-general] doubts about rolling release
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.
Re: [arch-general] doubts about rolling release
Thank guys for the reply! On Fri, Mar 7, 2014 at 3:49 PM, Ralf Mardorf ralf.mard...@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
