You are not logged in.
Hi all, I am wondering this because I want to build my webhosting infrastructure using archlinux, but I wanted to know, what pitfalls should I expect from doing this?
Will the rolling release model eventually become to dangerous for this kind of business? or make the infrastructure very hard to mantain? I just want to hear your toughts about this.
thanks in advance for the help
Linux user #498977
With microsoft you get windows and gates, with linux you get the whole house!
My Blog about ArchLinux and other stuff
Offline
Hi all, I am wondering this because I want to build my webhosting infrastructure using archlinux, but I wanted to know, what pitfalls should I expect from doing this?
Will the rolling release model eventually become to dangerous for this kind of business? or make the infrastructure very hard to mantain? I just want to hear your toughts about this.
thanks in advance for the help
The wiki does seem to want to portray Arch as suitable for servers. On the other hand, I don't think it's controversial to expect that rolling-releases with the latest versions of packages will break things every once in a while. It does seem like every time there's a kernel update, the forums get a few new posts about broken systems.
I like Arch, but if I was running a server that needed stability for webhosting, I'd probably swing more towards Debian. The Debian NetInst is similar to Arch in a lot of ways, in that at first you're just thrown into a pure command line with no graphics, and you build up everything else from there.
For me, Arch is a hacker's playground for learning more about Linux while having latest hardware support, but perhaps it is not the optimal choice where stability is necessary and good hardware support is already available.
Offline
That all depends on how confident you are maintaining an Arch server in a production environment. For some applications, I would feel better with a distro that has commercial support.
"Oh, they have the internet on computers now."
Offline
/dev/zero, thanks for your input, what its really making me consider this is the fact as a general rule, if you want a rock-solid system, you can't have the lastest programs and updates, however in my case, I see Arch defying this rule every day. I have installed arch on many machines by now (say about 5+ and I have used them all for extended periods of time) and I have experienced some hiccups regarding updates, but those tend to be big updates big userspace applications (say from Gnome 2 to Gnome3), on the server side applications (apache, mysql, ssh server, etc), I have never experienced any problems, thats was leads me to think this kind of setup could provide customers cutting-edge features while in a stable environment.
Please correct me If im wrong
Linux user #498977
With microsoft you get windows and gates, with linux you get the whole house!
My Blog about ArchLinux and other stuff
Offline
/dev/zero, thanks for your input, what its really making me consider this is the fact as a general rule, if you want a rock-solid system, you can't have the lastest programs and updates, however in my case, I see Arch defying this rule every day. I have installed arch on many machines by now (say about 5+ and I have used them all for extended periods of time) and I have experienced some hiccups regarding updates, but those tend to be big updates big userspace applications (say from Gnome 2 to Gnome3), on the server side applications (apache, mysql, ssh server, etc), I have never experienced any problems, thats was leads me to think this kind of setup could provide customers cutting-edge features while in a stable environment.
Please correct me If im wrong
Yeah, I don't think I can give you a definitive answer, and maybe one doesn't exist. It seems like you know your way around, so I guess you just need to decide for yourself whether you think you can manage the risks.
I mean, I certainly don't want to be seen as saying: "Arch is bad for servers". Probably, it will work fine. It's just that, for servers, I'm not sure it would stand alone at the top of my list. It might be second from the top, or there might be a tie with one or more other options that need trading off against each other based on things like stability, commercial support (as murffatksig said), etc.
Offline
It also depends on the type of business it is.
Are your users/customers going to be outraged and cause a fuss if there is some occasional downtime?
Edit: I may have typed faster than I read and misunderstood this as running your own site rather than web-hosting. Don't mind me, I know absolutely nothing of the latter.
Last edited by Trilby (2012-01-10 01:36:39)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
For web-hosting, isn't it common now to use virtual private servers, and the customer can have installed whatever distro they want out of a list of whatever you want to support? So if you're really keen to market yourself as offering the latest software to the discerning customer, an idea could be to offer Arch as one of the distros you support - but maybe keep Debian, Red Hat or a BSD on the back-end for stability/support.
Last edited by /dev/zero (2012-01-10 00:38:11)
Offline
Yeah I also tought of that approach, have a fully supported OS as the backend of virtual machines running Arch, but that would be for highly advanced users requiring the services I would offer and also not cheap (a VPS is way more expensive than a shared hosting solution), also not anyone needs a VPS. I am more inclined to help 'normal' people have a nice website with the latest software versions supported, for example, latest version of php, apache, Mysql, so they can have all the new features they can get, without the need to pass to a painfull upgrade process that could break things (for example, move to php v5 from php v4).
Like you said, It is a thin line with no definitive answer than only experience itself would tell what the best approach is. I also think I'm so in love with Arch that actually I want to involve it in every of my proyects
This kind of stuff can have only 2 possible outcomes:
a) It work beatifully, fast and light and everyone is happy
b) Works for a while then setup breaks into 8904238590 pieces so I have to rebuild using a supported distro and VPS with Arch on top
Im fine with any of the 2 because it a testing phase and nothing bad can come from experience, also I would of course start with my own websites so I am the only one having downtime in case of a disaster
Linux user #498977
With microsoft you get windows and gates, with linux you get the whole house!
My Blog about ArchLinux and other stuff
Offline
This kind of stuff can have only 2 possible outcomes:
a) It work beatifully, fast and light and everyone is happy
b) Works for a while then setup breaks into 8904238590 pieces so I have to rebuild using a supported distro and VPS with Arch on topIm fine with any of the 2 because it a testing phase and nothing bad can come from experience, also I would of course start with my own websites so I am the only one having downtime in case of a disaster
Since it seems like you're happy with the prospect of failure as an opportunity to learn, I say: go for it! :-D
Offline
I really think its not as unstable as you think. Just setup kernel-lts (ultra stable long-time-supported) kernel, set pacman to ignore updates to the kernel and key packages, go with proven applications and try to avoid AUR packages and it should run in a stable fashion for years.. Probably also a good idea to setup in a secure way (there is a wiki article on that) and you should be good to go, with minimal downtime IMHO. Hope it helps you..
Last edited by minimal (2012-01-12 03:03:43)
|\/|
_________________________________________________________________________________________
Never judge a man until you have walked 1000 miles in his shoes.
..that way you'll be 1000 miles away and you'll have his shoes.
Offline
Wouldn't ignoring packages defeat the purpose of Arch's rolling release system? Also if its not so unstable, then why ignore packages in the first place?
Offline
Wouldn't ignoring packages defeat the purpose of Arch's rolling release system? Also if its not so unstable, then why ignore packages in the first place?
+1
If anyone's going to go to all the trouble of trying to freeze Arch into place to try and prevent any instability, well, I think considerations like that explain why we have more than one Linux distribution to choose from ...
Offline
I can only recommend using arch for a server. I run a fileserver at home and a database (web-) server + 2 workstations at work. In my Arch life (4+ years) I had exactly 3 hiccups:
- years ago one xserver update was broken, which would not affect a headless server, of course
- postgres update 8 -> 9 required hands on to keep data, info was on startpage, so no problem at all
- early this year udev started assembling raid in addition to mdadm doing it. that was confusing and kind of a bug (only affected my fileserver, where / was on a raid as well) I ended up installing from scratch, but was able to keep my old /var and /home; so I did not loose any data. I guess there would have been a more sophisticated way to fix, but this worked quickest for me.
IMHO being able to jump quicker to php 5.4 (OO functionality) or to MySQL 5.5 (events) than on i.E. RedHat, weighs out watching your pacman output and arch news section from time to time. My server at work is critical and never let me down. In addition you never have to worry about a dist-upgrade or something like that ;-)
Of course, I don't update all machines at the same time ;-)
Offline
Of course, I don't update all machines at the same time ;-)
That's the key here: have two machines syncing manually all the time and test updates on one system before updating the other systems.
Offline
satchmosgroove wrote:Of course, I don't update all machines at the same time ;-)
That's the key here: have two machines syncing manually all the time and test updates on one system before updating the other systems.
wouldn't be better to have a kind of testing and packages to go into the stable repos when they are stable and would be nice to have a security mailing list like debian
Offline
zenlord wrote:satchmosgroove wrote:Of course, I don't update all machines at the same time ;-)
That's the key here: have two machines syncing manually all the time and test updates on one system before updating the other systems.
wouldn't be better to have a kind of testing and packages to go into the stable repos when they are stable and would be nice to have a security mailing list like debian
It probably would be better, but there's no such ML and how do you test the packages going to the repos? If few people use [testing], issues may arise only after these packages go to the stable repos.
Offline
And keep in mind: using debian stable does not mean, you will never ever have a problem. This topic always gets a little philosophical. You also have to feel comfortable / be able maintaining the system. For me, Arch is the distro I know best.
Offline
I would say Arch is completely usable for your server infrastructure provided you do a few things:
* Secure it. You need to know what to do here. Arch out-of-the-box is not sufficient, especially for a server.
* Test new packages before you deploy them.
It also comes down to the packages you use, and guarantee you'll have few problems with stability if you're mindful of the changes between releases. You could even wait a week or two before updating to the latest package, just to see if there are any reports about a package. You'll still your updates much quicker than you will on Debian or RHEL/CentOS. You don't need to depend on "stable" server distros that update their packages once every year and a half. Arch is still great for servers, but you do need to know what you're doing and you do need to be careful.
I've set up quite a few boxes for friends that use them in a server environment and they've seldom encountered any problems with stability, save an update a while back that affected the use of RAID.
TL;DR: Arch is great for server usage, just use your head.
Last edited by m4xm4n (2012-01-19 04:50:06)
Offline
Cosmin wrote:zenlord wrote:That's the key here: have two machines syncing manually all the time and test updates on one system before updating the other systems.
wouldn't be better to have a kind of testing and packages to go into the stable repos when they are stable and would be nice to have a security mailing list like debian
It probably would be better, but there's no such ML and how do you test the packages going to the repos? If few people use [testing], issues may arise only after these packages go to the stable repos.
Even if issues may arise only after these packages go to the stable repos a mailing list would still be nice or some sort of green or red light if packages have fixed security bugs and if packages themselves have new bugs that are known or when it's safer or recommended to upgrade.
Offline
hi! thanks for all the input, for some reason I didnt get the suscription email about this thread but I just read the entire responses and have a few comments/questions:
@minimal, great idea about kernel-lts, the only point I dont agree with you is regarding package freezing (only the kernel would make sense to me), I want Arch for the server infrastructure because of this exactly, latest versions and bleeding edge.
@m4xm4n, definetly both points are critical, not just in Arch but in any distro you choose for a server
@satchmosgroove thanks a lot for sharing your experience very helpful!
@Cosmin, yeah security mailing list would be nice to check for security updates and also, tips and tricks for securing the installation
And I have a question If I may, what if I wanted a cloud setup in the future? (I know little of this at the moment but not for long ) can Arch servers work together in a cloud environment? Any experiences with this?
thanks again
Linux user #498977
With microsoft you get windows and gates, with linux you get the whole house!
My Blog about ArchLinux and other stuff
Offline