Mashkin

You should note that FreeBSD is not really good with cross-platform compiling/debugging. Since game files are usually compiled for x86 (32bit), debugging on an x86-64 machine is quite hard. I usually use an x86 VM or server for debugging instead of messing with this issue.

I only discovered this checklist now, and I must admit it gives a very good introduction to fundamental security practices. I would enjoy reading the rest of your explanations on the missing topics. As a (successful) long-time system operator myself, I can nothing but approve this checklist, and urge everyone to educate themselves on systems security. What makes this thread a little unfortunate is the fact that it is required to teach technicians/admins the most basic principles of securing their systems. Everything written here, except for the game related chapter, is something every sysop must know before they may claim to be a professional. Missing these "skills" is - in my eyes - the primary reason for the enourmous amount of database leaks. Missing knowledge in general is what I believe to be a major reason for many project failures - set aside "money machines".

What is your system architecture (use uname -m to determine)? The source code has been written for x86 systems and many data type usages depend on that (int, size_t, long are all 32 bit long on x86). If you are trying to compile the source code on amd64 archtecture (64bit CPU and OS), you will encouter many errors because data types are different (int and size_t are 64 bit long, long is [at least but usually] 32 bit long). Refactoring the code to use data types consistently will probably be a very extensive task, so I recommend you setup a 32 bit system (possibly in a VM).

I have to admit I didn't work with autoloading yet. I would really appreciate if you participate at this point. I don't even know if there would be compatibility problems if the homepage where the lib is used in has an autoloader itself too, so i just used the method i got teached about a year ago at work. About namespaces: Namespaces are a great thing but like you said not useable with all php versions and I wan't this lib to be useable whereever possible Decisions have to be made, anyways. As you don't know the version constraints right now, you could very well have some incompatibilities with old PHP versions already. Namespaces have been added as core feature with PHP 5.3. PHP 5.3 has reached its end of active support in mid-2013, and end of live passed in mid-2014. Even PHP 5.4 is about to reach its end of active support in two months, so one could expect that namespaces are reasonably adopted by now. You can see a list of added features in PHP 5.3 here: [Hidden Content] As you will see, even __callStatic() has only been added then, so you already require at least 5.3 for your library to work. Entire (now widely used) frameworks like Symfony2 build upon PHP 5.3 because of e.g. closures that have drastically changed application flow, because event-based structures became easy with callbacks. I would never encourage any PHP user to employ or keep an utterly outdated version just to support the very few ones that didn't yet update their systems (newer stable versions have been available for 2 1/2 years). Espacially not in the case of PHP 5.3.

You could enrich this feature by adding JS-based browser geolocation. Maybe some server-side code for implementing and processing JS geolocation would be helpful. As it is, most mobile devices today provide means to acquire its location, and even desktop browser can easily determine the location without GPS (I didn't expect that until I tested it myself - [Hidden Content]). This might be not very common in the sphere of Metin2, or helpful in location-based service restrictions or logging, but it can impact location-based services like "What's around?" services. This is just because I haven't seen much adoption of browser-based geolocation features yet (outside of native mobile apps). In general, I would love to see some information about required the minimum PHP version, and especially about the code structure/pattern. For one, I must say that I dislike the used __callStatic() pattern. I would much prefer to see an autoloading-based aproach, where the current "core class" can effectively be replace by any comliant autoloader, like C omposer. If PHP versions prior to 5.3 (DEPRECATED!) are out of scope, namespaces would be a great addition to divide different feature sets. Doing so could later allow you to propagate the overall package - or parts of it - on e.g. Packagist, which would make installation and updating easier and will also encourage new developers to adapt clean, modern code organization.

[Hidden Content] Missing braces around blocks can easily lead to false branching. I think your project needs some clear (rough) aim so interested developers can think about what could benefit this project. There are already plenty of specialized libraries for e.g. database abstraction. There are also many sites providing useful classes and helpers (with questionable code quality, maybe). What I'm actually missing is an easy Bootstrap widget system for PHP - there are some for several frameworks but not for plain PHP.

This happens to virtually any host once it is exposed to "teh Internez" for some time. Just like on my private virtual servers: There were 70877 failed login attempts since the last successful login. Last login: Tue Nov 11 11:44:17 2014 Notice that this server was offline the last three days, so in fact this is the number of bruteforce tries for only 72 hours. You can install stuff like fail2ban or do "rate-limiting" on your SSH port, but you should start out by making sure your credentials are secure. This also includes using a personal user, and not root, to login - only switch to root user when necessary using su or sudo. Choosing an unusual name already does alot (e.g. jpryan34 instead of just ryan) since most brute force attacks aim for "standard" names like root, toor, anonymous, apache, mysql, daemon, httpd, nginx - usual daemon/system user names john, jane, lukas, michael, robert - usual first names

In the base system, yes, FreeBSD finally moved to Clang for licensing reasons (GCCs GPL is considered too restrictive for the BSD license family). It should still be possible to use GCC after installing it from pkg/ports, though. It is also possible to use Clang for Metin2, but some code changes are required. This mainly applies to some include files with preprocessor directives. There are some non-standard language extensions in GCC. The code is written to use Boost components as a replacement when not using GCC (e.g. on Windows), but unfortunately Clang defines the "__GNUC__" makro used for this purpose. After changing the conditional defines, Clang should compile everything just fine. Also note that you should link to libc++ instead of GCCs libstdc++. The server works, but I don't yet know how stable it is.

You can easily configure your virtual server to have two NICs attached, one with access to the internet (through your usual local network) and another one linked to Hamachi. Beside the networking issue, yes you can use source code for a Hamachi-connected server, since it is no different from any other server except connectivity.

Just like anywhere else, my dear. Using this all the time. Twig is good. However, even Symfony (which is the number one framework to use Twig) offers PHP "templating". BTW, props to the OP for showering in only eight minutes. Seems like getting an account on that server got you quite excited. Hennink's script was pretty fine back when it was written. It is "designed" like many not-so-optimal scripts, and there were quite some critical flaws, which eventually got patched individually over time. It was also back then (and still, to some extent, is today) when php-mysql was simply the most common MySQL API in PHP with the highest likelyness to be available on almost any PHP installation and hosting provider. The PHP landscape changed a lot in recent years and frameworks as well as object orientation are omnipresent now.

Well some suggestions for your script stuff: Don't do ipfw restart when adding IP bans, this will break all your dynamic rules, e.g. if you have anything like allow tcp from any to me 13001 setup keep-stateall your clients will be kicked as the dynamic rules table is flushed and no packets of already open connections will match setup (which is for reason). Don't just append the rule for an IP ban to the ipfw.rules file with rule number 1, this is dirty and unperformant.Rather use an IPFW table: /etc/ipfw.rules: ipfw add <XXX> deny all from "table(1)" to me ## <XXX> is some rule number smaller than your allow rules # Load blacklist from file: while read line do ipfw table 1 add $line done < /etc/ipfw.blacklist Ban command: ipfw table 1 add $ip echo $ip >> /etc/ipfw.blacklist Unban command: ipfw table 1 delete $ip ipfw table 1 list | awk '{print $1;}' > /etc/ipfw.blacklist ## awk removes the value from ipfw table command outputWith this you can even ban whole ranges like e.g. 192.168.0.0/16. Though you cannot remove a single IP out of this range but only the whole range at once.

When they went offline they claimed to have been scammed by Voxility, the latter confiscating bought hardware and whatnot. This apparently was not the case, there has neither been any info on the lawsuit Xertonia wanted to initiate, nor did their customers ever receive the promised paybacks. When I had a little talk with "Alex" a.k.a. Paul, he revealed the hosting actually consisted of 20 dedicated servers, two storage arrays, and two top-of-rack switches, all of which Voxility offers both, for rent and permanent purchase with their colocation offers. The bandwidth Xertonia sold was best-effort bandwidth, without any garantuee. Back to present time: Xertonia.com is online and has a new design with a 2014 copyright, so they might be planning a comeback. Worldstream: Hosted my private servers years ago, pretty reliable and the support has always been nice, even offering a free secondary HDD when my system crashed (they never removed it afterwards). A friend of mine reported that once they had a disk failure and no RAID which was awful. They also said they were taken down with a complaint from .SG. I guess the nice support went away when Metin2 "admins" started to repeatedly bother the staff members with "dumb" questions - besides those kids being totally unfriendly and rude most of the time. I have seen numerous screenshots/copies of mails to WS's support staff and I can tell you I wouldn't stay nice and cooperative either. Today, WS is still in use for development/testing servers as those are unlikely to be found and taken down by anyone. Hetzner: Definitely not the right choice for Metin2 Servers. The server my former admin had was taken down in less than one week after public launch due to copyright infringement (I am not certain anyone ever filed a complaint). OVH: Never used, years ago it appeared to me as a "shiny plastic-thingy for some unprofessional people", well that seems to be different. I am getting positive feedback on them. InterNOC24: Reseller of Voxility. They accept PaySafeCards. The support was slow and unwilling in many cases.Uptimes were medium and we had issues sometimes - mainly because there wasn't ANY (D)DoS protection, finally driving us to migrate to ... Incloudibly: Best hoster I yet experienced, with fast and competent support staff. Their traffic filters are doing a good job and we never had any technical issue with the several servers we have. However, they are expensive, probably making them a no-go for newcomers. Their features are good, containing whitelisting for the protection, PTR record editing and all-time free KVM/IPMI (remote console, cold start/reset etc.) access, though the SuperMicro controller in use there sometimes bugs. Server4.pro: Reselling several other hosters, including WD, OVH etc. Accepts PaySafeCards. All theri VPS have soft-limitted bandwidth ("100 MBit/s on 1 GBit/s link") which is a pain. Linux traffic shaping/bandwidth limiting doesn't work in the virtual environment and servers get suspended when going over the contract bandwidth for more than a few minutes. These VPS are also suspended when the system load rises above some value. My two 6€ VPS have been suspended at least 4 times each in the last 6 months, forcing me to contact support and ask for reactivation. The VPS are sometimes rebooted without prior announcement (at least not via email) which really sucks.

We have multiple login servers running and the client simply iterates until one works. Well, to go deeper into the protection service thing... with the source it would be quite easy to implement a reverse-proxying scheme so one dedicated game core could be behind a number of proxy peers that preprocess and filter traffic. Then you can add a random/round robin connection routine to your client. Oh yes, and you would have to find some way to announce multiple IP addresses for a single core (unless you are using Anycast like Cloudflare does). I'm just thinking about using DNS SRV records or s.th. like this.

Doesn't mean you'll have a safe launch. The section has many faggots threatening you with attacks and demanding money. We've been doing well for months with Incloudibly, our downtimes from attacks were short and as the hoster's and our filtering rules were optimized, downtimes completely vanished. Besides, Incloudibly has a decent support team and some nice "pro" features included (like all-time KVM access).