hello the question is already in the title,
currently iam satisfied with centos on the other hand ubuntu should more reliable,
what would you choose?
greetz
hello the question is already in the title,
currently iam satisfied with centos on the other hand ubuntu should more reliable,
what would you choose?
greetz
Never used centos,
Most of my server run on ubuntu, as it is mostly easy to maintain, and set up in a few minutes.
-> you can set it to automatically update critical security updates
-> Can use debian binarys, so almost every stuff will work.
-> no rolling releases, distribution upgrade always sucks
-> Ubuntu team has sometimes crap in the repositories (eg in 13.10 the gradlebinary just segfaults, a manually installed one works)
-> Also funny in 13.04 the cmake had a bug, prevending jme bullet to be compiled, but probably not that important for a server
Then I also use arch linux
-> rolling releases, always state of the art software and not old stuff
-> at least 8 hours to setup and configure system (eg the âliveâ install system is a shell, has no services runnin ect.)
-> pacman is so far the best and most reliable packet manager I have used.
-> Extremly active comunity + relaxed open source bitchery -> you get commonly used closed source stuff installed from the packagemanager -> aka it is also autoupdated
So for a server I would say ubuntu, as it should mostly work. For a customized Desktop arch linux.
Also if your server already works, just leave it be, the differences are not that much between differnt shells
Is the server a target for internet criminals, and if yes, how easy would an attack be?
If you move money (even just payments of your customers), then the server is a target.
If you use PHP, an attack would probably very easy. If you use Linux, an attack would be easy for somebody with a zero-day exploit - such an attack would cost a four-to-five-digit sum, so you need to start worrying when/if your server is handling a total volume in that order of magnitude, but at that point, Iâd want to move to, say, OpenBSD.
Actually I donât think openbsd would be safe(er) at all, as it uses mostly the same applications, and is not as much testes, and partly lagging behind.
Not using a windows server, is around half of the work. (and even they are capable of being hardened properly, itâs just more work)
Well, all I got from Linuxâ better testing is a steady stream of almost-weekly security updates for the kernel. I find that quite disturbing.
OpenBSD starts with an everything-is-disabled-by-default configuration, so you KNOW what youâre opening and why and where you need to be careful. Even with the mostly same applications, this approach is going to produce more secure boxes.
I donât know whether OpenBSDâs lack of security fixes is just because nobody is looking or because the quality is better. Given that OpenBSD is actually in widespread use (just not very prominently so), I suspect itâs a bit of both.
I think itâs partly a consequence of the development priorities.
Linux is open to experiments. Huges swathes of code are being continually added and removed. You canât security audit everything.
OpenBSD is more of a cathedral approach. A close-knit group of developers, everything is constantly being security reviewed; development is, by necessity, slower, but the default maturity level of the code that goes in is higher.
Given that a server with a single application doesnât need much in the way of features, Linuxâ strong points donât matter that much.
Can OpenBSD run Java? Then itâs good for a JME-based ServerApplication.
Can OpenBSD run a web server with forum/bugtracker/tickethandler, can it do SMTP/POP/IMAP? Then you donât even need a separate server for that âother infrastructure stuff that a company needsâ, at least not until load becomes a concern.
Iâd still make any server software runnable under both Linux and OpenBSD, simply to be able to set up test servers and because developers and testers will more likely have Linux than OpenBSD. But then itâs Java, so thatâs a non-issue (or is it?)
Everything is disabled is for almost all linux server distributions the standart (eg ubuntu, debian ect)
(You dont plan to host directly or? a virtual machine greatly reduces work for backup and restoring stuff)
If you use arch linux for example you are right much code is beign added and changed (but you also get the security fixes earlyer as its packages are directly pulled from the sources),
then there are the stabler distributions eg. debian lts, wich is quite conservative in that regard and almost never adds new stuff if not absolutly necessary)
Reason against openbsd no KVM or vt-x suport nativly as far as I know. Best for security is if your gameserver is not also your mailserver and your webserver
Make a virutal machine for each, and if one gets corrupet, at least the rest is still save. (and if you are paranoid make the virtual machines then openbsd)
Regarding java, does open bsd accept linux natives? else you will eventually have no fun with bullet, lwjgl and other jni based stuff.
Oh no, most Linux distros come with tons of services running.
I wouldnât use a virtual server. You donât have control over how much CPU the other users occupy, and youâll never be able to control server-side lag.
(Applies only for real-time games. For turn-based games, a vserver should be fine until it hits capacity limits.)
No KVM/vt-x: The argument against virtualization is that it adds more complexity than can humanly be security audited. I.e. youâre adding more barriers but weaken the overall structure; the overall security gain is indeed questionable, it improves security against script kiddies but make it easier for professional attackers who now can attack both the guest kernel AND the virtualization layer. Throw in the ickyness and complexity of hardware virtualization support on x86/amd64 and you have a veritable mess.
For a machine thatâs dedicated to game servicing, you donât need to virtualize anything anyway.
Yes, OpenBSD does accept Linux natives. The Linux userland-to-kernel API has been ported to OpenBSD, and Linux binaries can run on OpenBSD. I havenât verified that shared libraries can, too, but Iâd expect them to.
I wouldnât use a virtual server. You donât have control over how much CPU the other users occupy, and youâll never be able to control server-side lag. (Applies only for real-time games. For turn-based games, a vserver should be fine until it hits capacity limits.)
Soory but it is possible, that is in fact no problem at all with kvm, as the virtual machines are just normal processes, and are for example controllable by the nice settings. My current test server runs on a vm, and I have no problems getting it fast enough. (Note: I speak about a own root server with own vms on it, not shared hosting)
Oh ok, if you control the real machine then you can indeed allocate resources.
I still donât think that KVM really buys you that much: OpenBSD without KVM is more secure than Linux with KVM.
See these web pages (most relevant column is âgain privilegesâ):
Linux kernel: http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
KVM: http://www.cvedetails.com/product/15752/Kvm-Qumranet-KVM.html?vendor_id=8922 (okay, thatâs really not that much)
OpenBSD: http://www.cvedetails.com/vendor/97/Openbsd.html
Seems like KVM can indeed mitigate attacks, but youâre exposing a much larger attack surface using Linux.
Iâm not even sure that OpenBSD is less well-tested - sure, thereâs less man-power behind them, but whatâs the number of eyeball-hours per line of code, better or worse than Linux? Plus OpenBSD is less interesting to attackers so youâll get less script kiddies right from the outset.
I certainly wonât make any hard claims, but I doubt that Linux+KVM can be claimed to be safer than OpenBSD in seriousness. Not without a lot more substance on the statistics and backgrounds anyway.
Well the question was not soley about safeness, and then the kvm combi is preferable.
-> easier backuping
-> cleaner speration of concerns
-> easier to just test out something without spending much time to clean your root server up.
After all linux and virtualisation should be safe enough for normal business (aka google, amazon ect, as they are certainly targets that are interesting on the money account.)
If you are specifically targetet and someone invests a sum of 5 digits into getting your money, I would be more concernd about somone knocking at the door with a pumpgun, and forcing you to transfer it to some offshore account
Well, no i dont whant to host at home, my server-network shall in final state
be a a jmonkeyspider, i will embed ObjectDB and see if it is clusterable as embeded over Terracotta, there will be several modules like H.264 video streaming for tactical briefing, so as you can see the needed bandwidth would be realy high through the video / audio part, everthing should primerly run in a webbrowser envoirement as Applet with 2 or more different sockets to allow flexibility and part the bandwith needed on differen serversâŚ
Only for development i do nee private hosted server.
As i think anything i choosen are production ready apis for me are 3 things importent
thanx for your answheres
So you will eventually be using something like Amazonâs data services for your bandwidth needs? Or do you have some other provider in mind?
Figure that out and then get the most-exact compatible thing possible for your private dev server.
Reliability & speed: Depends less on operating systems and more on what kind of application programs you use. PHP is worst, Java is better, if you want to simply deliver fixed files Iâd go either with Apache (very old and reliable, somewhat quirky, decend speed) or Lighttpd (quite solid though not as much as Apache, leaner&meaner, somewhat simpler to configure).
Youâll probably find that most reliability problems will originate on the browser side.
Streaming speed is usually not that big of a problem; unless youâre doing something unusual, most players wonât be seeing briefing videos at any given time, so video bandwidth isnât going to be eating up your server. It can be a problem on the client side - thereâs a surprisingly high fraction of badly-connected people out there that canât even use Youtube. If you want to reach these as well, plan to preload the briefing videos as low-priority data stream in the game data socket.
Security: Irrelevant for the test setups that are unreachable from the Internet.
If itâs reachable, some degree of paranoia is advisable though you never know whether youâre overparanoid or not, you only know if you have been underparanoid, after you learn you have been hacked.
Youâll need to put user logins and anything money-related (payments, monetary rewards to players if any, credit card info) into one machine, modifiable game data into another, constant game data into a third.
The third machine is because itâs easiest to split up into multiple servers to reduce per-machine load; data thatâs being updated is awfully hard to keep consistent across machines, most schemes that do this are either not as reliable as one would think, or incur latencies that can very easily become unacceptably high.
Also, read-only data is usually not very interesting to an attacker so youâre reducing the attackable surface a bit.
It seems itâs open to debate whether one should rather go for physically separate boxes with OpenBSD (my approach) or a Linux box with KVM and virtual machines is enough (Empire Phoenixâ approach). Obviously, either of us has been remaining unconvinced of each otherâs approach, and I know of no easy way to decide which approach has more merit, other than trying out both and see which one gets broken more often - an experiment thatâs usually outside the available time and/or monetary budget.
ok in case of i also need to reset my Server i will Test with different distrus and choose afterwards, thanx again
As we speack over webservers I want to mentions nginx if we speack about reliable an fast. (and nodejs if we want javascript on the server, I feel not very good with his tho) In fact there are very few virtual machines (in term of langageus aka jvm) that I would seem as production ready, mostly the java and the .net one.