freghar

So this is where all the botnets come from ..

Well the point is that not everyone has public dynamic IP or several SOCKS proxies available, so IP banning is effective even if the user isn't 12-year-old kid. However .. http://www.google.com/search?hl=en&q=change+MAC+windows Anyway - whatever. If you want it, I won't stand in your way .. My opinion is that mangos should provide only account-level and character-level banning, network-based bans (IPv4, IPv6, MAC, any tunnels (L2TP), ..) should be done externally.

Frankly, that's nonsense. There's absolutelly NO security when it comes to MAC addressing. Really NO security. Mac-level addressing is used only within one subnet, ie. in LANs. It doesn't go over routers. So fine, it would be good for LANs at least ... no, wrong. As I said earlier, you can very easily (in GNU/Linux, Windows, all *nixes I know) change the mac address of your card in a driver. So that you ban one user, he changes it to 44:55:66:77:88:99 and plays. Now you could say "well I can at least allow several MACes and ban the rest". I had a real reason saying "NO security", this wouldn't work either. A banned user can change his MAC to already used one, making possible problems along the way (google for "switch port stealing"). If the network runs on IPv4, it can do even more - block someone else by spoofing an ARP reply of the mangos server and connect to the server under his identity. That way you can't even detect race conditions on the server machine (= spam of ARP packets, there will be none, since the original (now blocked) user uses nonexistent MAC, not the server's one). It's very similar to IPv4 address "model" for LAN and connected with it via ARP. Ie. you can have two machines with the same IP address in the same subnet, but they will "fight" with each other about the place in server's ARP table. Well, the flood way mostly works.

I have to disagree. The best security is to allow only localhost

Yes, it's easily possible to get first 14 bytes of a packet using RAW socket, but ... it has no real use for mangos. Use firewall if you want to do ban-by-mac .. however be aware that the address can be easily changed on the card / in the driver, so it's ineffective.

This topic was meant as discussion, not an announcement. I wanted to hear your opinions on that idea, both from patch developers and testers. If, however, there's noone interested, it shall fall into the "maybe someday" category.

In fact (IIRC) if they don't provide the source code along with the binaries, they're breaking GPLv2.

Added new article about patches called "The reviewing maintainers problem". Read it here - http://repo.or.cz/w/gitlog.git?a=blob_plain;f=html/08_The-reviewing-maintainers-problem.html;hb=master.

Hi all! I recently got an idea how to make big patch testing possibly easier for both users and developers, I used the idea behind old Andrew Morton's -mm tree (mm = memory management originally) - testing patches which weren't ready for upstream. So what I want is a custom tree (repository), maintained by myself, which provides a stable base for several patches for a period of time. That means "we stick with rev 12345 for, say, 14 days and instead of fixing our patches AND making them work on newer revisions, we focus only on patch bugs". After those 14 days, my tree gets updated to new revision and all patch maintainers should merge mangos/master, resolve conflicts and send me a pull request (via email, forum, automatically via cron or special github interface) and I shall include them in my tree for the next 14 days. If any bugs are found in any patch within those 14 days, testers can report the bug, developer fixes it and then sends pull request / wait for everyday automatic pull and the fix gets to my tree as fast as possible. End users also gain an advantage. If you look at the patches now, everyone tries to be "on latest rev", but that's changing every day several times and none of the developers is able to update and post new patch say six times a day. That results in patch incompatibility, not that the patches are conflicting with each other, but each of them is made for one or another rev, making them unusable together in most cases. So the end user would simply clone my prepared tree with patches compatible with each other on revision level. ----------------- An example: Ambal wants some testing for some of his patches, say the "updating map system" one. At the same time, balrok/bogie wants to test Alterac Valley patch. And additionally, hunuza's "getting rid of the data blob" patch. So they prepare their patches for a pre-announced revision and let me git-pull from their prepared branches. End users gets the result, test it and report bugs found. If there are any, they get fixed + fixes pulled to my tree, still on the same announced revision. After some time (~14 days) a completely new tree is created from mangos/master, Ambal, balrok/bogie and hunuza gets their patches updated, pulled by me and the testing continues. ----------------- To cut this short - yes, it's not completely clean solution. Patches may conflict with each other, but if they do, they are related to each other, meaning their developers should communicate and develop together, for example dev A does some framework which dev B uses, so B pulls from A, updates his work above that and sends me a pull request. If two patches are related to each other, but don't conflict at code level (API in src/shared/ by developer A .. versus functions using it in src/game/ by developer B), developer B can pull from A, but at the same time I can pull from A as well and the resulting merge will not conflict in any way. See examples on http://paste2.org/p/335508 . The second problem are crashes and/or functionality anomalies. They shouldn't get really bad in most cases and if they do and we won't be able to determine the reason easily, there's a nice tool called git-bisect, which can help us here, but I don't expect really big problems that often. So when a new big patch is to be added, it should be at least lightly tested (ie. it does compile, doesn't crash on start and such), this tree is just to fine-tune patches, catch (hopefully lesser) bugs and make improvements + get feedback on them. Finally, as I can see around the forum, we don't have a lot of testers willing to post crash dumps or provide useful feedback, and those that wish to, are divided amongst large patches. What I want is just to "merge" them together, so that the testing would be as efficient as possible. It's just an initial idea, it can and WILL get improvements, what I want is to know the real interest of testers and developers in such system. You don't have to fear about current mangos development style, this is just MY tree, mangos development can continue in a normal and usual way. Thanks, Freghar.

Oh, right. Maybe I remember it incorrectly or it was a typo in some old Gentoo documents. It makes more sense with CFS scheduler indeed.

Well the recommended -j argument value is (n*2)+1 where 'n' is the number of CPUs/cores.

Yes, but git can't resolve possible conflicts for you. If there are any conflicting lines, you'll get conflict on both pull and patch apply. You can generate a diff against clean repo by something like "git diff origin/mangos-0.12" or stash uncommited changes using "git stash", then apply them with "git stash apply".

Provide more infos; what does work, what exactly doesn't work and what exactly do you want it to do.

Pointers are probably the most powerful thing in C and pretty important in C++ as well. That means there's a LOT of tutorials explaining pointers from every possible angle of explanation. IMHO the easiest way of understanding pointers is to realize what they actually are. A four-byte (on 32bit machines) or eight-byte (64bit) locations in memory, containing a destination address they're pointing to. Nothing more. All those types of pointers (like int*, Player* and so on) only allows you to easily manipulate with the destination target. A pointer has still 4 (8) bytes. That's why you actually can use a void* and then typecast it like ((Player *)my_void_ptr)->GetName(). Pointers are simple once you understand how they work. edit: just an example I used some year back in a Linux kernel module; char *buffer; __u16 ip_csum; __u16 tcp_csum; buffer = skb_network_header(skb); ip_csum = ((struct iphdr *)buffer)->check; tcp_csum = ((struct tcphdr *)buffer+sizeof(struct iphdr))->check; (I ofc omitted a lots of checks and such) This way I'm able to get both IPv4 and TCP checksums from a packet using only one generic *buffer pointer (there could also be a check for IPv4/6 and doing all the work with only "buffer"). In practice it's better to use more abstraction layers.

search "old revision"

That's what you should do. I sometimes try to encourage developers to split their changes into small commits, so it's "one commit per feature / fix" rather than "this commit contains my today's work". It works well for the most part, so you should be able to just revert this one.

I guess that /commands are handled only by the client (in most cases).

I sent an email yesterday about this, should be better soon.

Some kind of a lock (mutex-based, spinlock, semaphores, ..) or atomic operation(s).

I don't think so.

Hello, I would like to "introduce" my new "blog". It isn't really active journal of my life, I would call it rather "article storeroom" - http://repo.or.cz/w/gitlog.git . I've converted all my articles from here to valid XHTML and put them there, including some stuff for devs on mangos private IRC channel which, unfortunately, never really got public. You may come across "gitlog" project on github, I wanted to have it there as well, but (as explained there) github doesn't allow transfering documents based on different MIME types, it only sends plain text. That means you can (well, could) view files in my blog on gitbuh, but in raw xhtml form, the browser didn't parse them as (x)html. Fortunately, repo.or.cz git hosting service does the job well. So, if you want to browse my (b)log online, go to http://repo.or.cz/w/gitlog.git?a=tree;h=refs/heads/master;hb=master. You can read all the stuff around. To browse an article in it's full XHTML form, click the "html" directory. You should see a list of available articles. To view any of them, click the "raw" link at the end of each line, not the filename directly. You can also click on the filename and the "raw" will appear in the top left corner. Since all of them are written in very simple and strict form, even text browsers such as lynx, links, elinks shouldn't have any problems. And because everything in there is on git, you can clone it or provide a mirror if you want. Happy browsing! note: If you come on the repo's "front page", don't click on commits adding new articles to view those articles. They add OLD version of articles. Such articles can be changed in further commits, so, please, just browse the latest tree to avoid confusion (on the bottom of the page are heads, just click the "tree" link on the "master" line).

What is so insecure about running a webserver chrooted into /var/www/ ?

I don't know who started this "mangos is emulator / isn't emulator" thing, but the wikipedia states so the question is whether MaNGOS tries to "emulate" some other <unspecified here> service or if it takes a completely independent way.

... or use ssh secure tunnel to connect to DB remotely

My first thought was .. oh god, another person opening old topics.