VegaStrike Online MMO Server
-
- Hunter
- Posts: 70
- Joined: Sun Jan 19, 2014 5:02 am
Re: VegaStrike Online MMO Server
Server offline until further notice - upgrading host.
Hope to have it back shortly, might have some teething issues with OS, as it's been a while since I've done this I may forget a few things I've done to make it work. I'll make notes this time.
Hope to have it back shortly, might have some teething issues with OS, as it's been a while since I've done this I may forget a few things I've done to make it work. I'll make notes this time.
Multiplayer Server Offline. Copy ony testing rig semi-funcitonal.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
-
- Hunter
- Posts: 70
- Joined: Sun Jan 19, 2014 5:02 am
Re: VegaStrike Online MMO Server
Well that was a mission. But it's at the minimal qualification for "operational" again.
Had a nightmare with almost every OS applied - the hosting companies images are completely screwed. I've still a few things to do, with regards to it's long-term resilience, the server component isn't upping at boot - but the registration/SQL transport is. There's also an issue with the users it's launchin registration as, but I've logged in flown about n shot things. Looking pretty.
I also took some notes, as it seems to be something of a repeat topic and there's no clear documentation on this I was thinking I'll mush together some how-to to post in here, and update the wiki with procedings. Installing this I noticed the server component is still using py2 for things - like MySQLdb, Which doesn't exist in py3. Might have a crack at updating that some day.
TL:DR;
Online and wasting time:
Had a nightmare with almost every OS applied - the hosting companies images are completely screwed. I've still a few things to do, with regards to it's long-term resilience, the server component isn't upping at boot - but the registration/SQL transport is. There's also an issue with the users it's launchin registration as, but I've logged in flown about n shot things. Looking pretty.
I also took some notes, as it seems to be something of a repeat topic and there's no clear documentation on this I was thinking I'll mush together some how-to to post in here, and update the wiki with procedings. Installing this I noticed the server component is still using py2 for things - like MySQLdb, Which doesn't exist in py3. Might have a crack at updating that some day.
TL:DR;
Online and wasting time:
Multiplayer Server Offline. Copy ony testing rig semi-funcitonal.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
-
- The Shepherd
- Posts: 5841
- Joined: Fri May 13, 2005 8:37 pm
- Location: Ottawa
- Contact:
Re: VegaStrike Online MMO Server
Why does that not surprise methe hosting companies images are completely screwed
![Twisted Evil :twisted:](./images/smilies/icon_twisted.gif)
![Question :?:](./images/smilies/icon_question.gif)
Enjoy the Choice
![Smile :)](./images/smilies/icon_smile.gif)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
-
- Hunter
- Posts: 70
- Joined: Sun Jan 19, 2014 5:02 am
Re: VegaStrike Online MMO Server
Heh, it's a VPS, shouild be more than capable of most task. It was working fine previously, but the OS was EoL. Minimally fail2ban was exploitable resulting in third parties being able to remotely prevent it from functioning as expected. It had to go.
First I kicked off with CentOS 7 - I like RHEL and I'm cheap. I had issues getting vegastrike compiled and running on 5/6. Installed OS fine, first yum update -y killed the install. I'd conveniently wasted the time of xfer'n 15GB of backup to it. Even @ 11MB/s that takes too long. The update rolled fine, it seemed - but after odd dbus msg's. Systemctl impotent. Remarkably similar err I finds online suggests re-install polkit -> reboot. Can't talk to init to reboot. Or Shutdown. Companies panel has issues putting it down. Doesn't come back up. Serial console reveals lacking NIC. Three install/config/repair attempts later I decided the image is completely borked.
Try fed, latest they've got is 20 - Pretty sure that's EoL, but fedup it to 22, then have dnf pull it up to 23. Should be simple. It got all packages up to 21, then complained there's no upstream kernel(?) to install and refused to go no further. Same story with 22 and 23.
Debian seems reliable? well, 8 ran for about 30s before, surprise surprise the NIC absented itself. On reboot that wouldn't re-manifest. Wouldn't respond to serial console or panel with suggestions to either reboot or shut down. Panel was unable to wipe it and install OS over top for almost 8hrs. Impressive.
Eventually got 'buntu on there. meh. At least it has service life for a little while - but this is a headache required to be approached again shortly.
Ofc, there's no VS in 14.04. The vegaserver component seems a rareity too.
When putting the pieces back together, I kinda made some notes. This will form the basis of a "how to" for anyone else wanting to replicate a server up, once I stop being lazy. This will include observations of it's failings in long term operations, and the steps I've taken to circumvent. Before I actually post it in forum & wiki I'll also include up some template/skeleton SQL to import to form DB nice n proper. Give it a little bit of a tidy, strip it back to essentials and pack up the sitework(the PHP-based user registration to bypass the accountserver.py and isolate 8080 from external access, The ship adjustment form - and over time other things that actually work, ish)
It's buggy(but better than before I started fiddling), but it's running. As long as the container doesn't reboot then it should be somewhat persistent. Uptime before I took it down for nuking was about 480 days or so. It's currently pootling along @ ½GB o RAM. 0.00 load avg's (only me logged in, unfortunately. But i've put a few clients on it and wasn't able to draw notable loads). I've not got RRDtool graphing it's stats yet - I've installed RRDtool, the previous scripts should be good, I'm just too lazy to make another screen session n start the data collecting(for some perversion, the same script won't work via cron). Wasted two hrs with getting cockpit on there - then fighting it locally 'cause it was crying the fingerprint changed. Finally found cockpit's known_hosts and removed the offending entry then it wouldn't connect anyway. Supposedly there's no support.
One day I'll get more things in more of a semblance of order. Want to learn some tweaks to it, like putting AI ships back in.
Finding out how the guilds be working.
How the "admin mode" over the in-game comms system gets used proper, and maybe reverse engineering some sort of HTTP/PHP interface. Admin panel. Once I've clocked how it's doing what it can does, I can in theory make it do more, too. Like pull out number of users online, in a specific system etc. Maybe eventually has some sorta screwgle-earth-esque galaxy map indicating locations of players - the uncloaked ones ofc.
The "public terminal" in the bar I think can be used to create an "economics submenu" - and using Nido's "markets" as a core begin to impliment individual and faction/gulid ownerships of production resources.
Figure out what the deal is with ships with turrets and sort that out.
Get it so players can own fleets, hopefully eventually even automated convoys of slower cargo vessel allowing them to fly the more intersting support/escort craft, controlling fighter wings...
One day.
When I've lurned me some moar python I'll consider having a stab at upgrading various things - like db.py - to python3. In that case there's MySQLdb which is depreciated. I'm sure equivical functions exist in supported libs - and maybe they won't go link-stale every 8hrs(clockwork). I suspect it's likely vulnerable too. Doesn't seem to be any sanity validation, assessment, or verification anywhere. Assuming random third parties on interwebs will provide expected input is most unwise(like having 8080 exposed leads to hoards of chinese attempting to leverage it as a proxy. accountserver.py likes that. Instant boom.)
The multiplayer facet is really the least finished part of the project IMHO. And with "modern" games it's not a feature that can really afford to be overlooked. It's gonna takes far too long for me to learn from fix it all. The amount of things I'll break on the way will be significant. Hell, I'm still failing on the preg_match to insert faction/ship selection from off the account creation form. I've working example code from the ship adjustment form too - it's only a few fields over in the save. Shameful.
First I kicked off with CentOS 7 - I like RHEL and I'm cheap. I had issues getting vegastrike compiled and running on 5/6. Installed OS fine, first yum update -y killed the install. I'd conveniently wasted the time of xfer'n 15GB of backup to it. Even @ 11MB/s that takes too long. The update rolled fine, it seemed - but after odd dbus msg's. Systemctl impotent. Remarkably similar err I finds online suggests re-install polkit -> reboot. Can't talk to init to reboot. Or Shutdown. Companies panel has issues putting it down. Doesn't come back up. Serial console reveals lacking NIC. Three install/config/repair attempts later I decided the image is completely borked.
Try fed, latest they've got is 20 - Pretty sure that's EoL, but fedup it to 22, then have dnf pull it up to 23. Should be simple. It got all packages up to 21, then complained there's no upstream kernel(?) to install and refused to go no further. Same story with 22 and 23.
Debian seems reliable? well, 8 ran for about 30s before, surprise surprise the NIC absented itself. On reboot that wouldn't re-manifest. Wouldn't respond to serial console or panel with suggestions to either reboot or shut down. Panel was unable to wipe it and install OS over top for almost 8hrs. Impressive.
Eventually got 'buntu on there. meh. At least it has service life for a little while - but this is a headache required to be approached again shortly.
Ofc, there's no VS in 14.04. The vegaserver component seems a rareity too.
When putting the pieces back together, I kinda made some notes. This will form the basis of a "how to" for anyone else wanting to replicate a server up, once I stop being lazy. This will include observations of it's failings in long term operations, and the steps I've taken to circumvent. Before I actually post it in forum & wiki I'll also include up some template/skeleton SQL to import to form DB nice n proper. Give it a little bit of a tidy, strip it back to essentials and pack up the sitework(the PHP-based user registration to bypass the accountserver.py and isolate 8080 from external access, The ship adjustment form - and over time other things that actually work, ish)
It's buggy(but better than before I started fiddling), but it's running. As long as the container doesn't reboot then it should be somewhat persistent. Uptime before I took it down for nuking was about 480 days or so. It's currently pootling along @ ½GB o RAM. 0.00 load avg's (only me logged in, unfortunately. But i've put a few clients on it and wasn't able to draw notable loads). I've not got RRDtool graphing it's stats yet - I've installed RRDtool, the previous scripts should be good, I'm just too lazy to make another screen session n start the data collecting(for some perversion, the same script won't work via cron). Wasted two hrs with getting cockpit on there - then fighting it locally 'cause it was crying the fingerprint changed. Finally found cockpit's known_hosts and removed the offending entry then it wouldn't connect anyway. Supposedly there's no support.
One day I'll get more things in more of a semblance of order. Want to learn some tweaks to it, like putting AI ships back in.
Finding out how the guilds be working.
How the "admin mode" over the in-game comms system gets used proper, and maybe reverse engineering some sort of HTTP/PHP interface. Admin panel. Once I've clocked how it's doing what it can does, I can in theory make it do more, too. Like pull out number of users online, in a specific system etc. Maybe eventually has some sorta screwgle-earth-esque galaxy map indicating locations of players - the uncloaked ones ofc.
The "public terminal" in the bar I think can be used to create an "economics submenu" - and using Nido's "markets" as a core begin to impliment individual and faction/gulid ownerships of production resources.
Figure out what the deal is with ships with turrets and sort that out.
Get it so players can own fleets, hopefully eventually even automated convoys of slower cargo vessel allowing them to fly the more intersting support/escort craft, controlling fighter wings...
One day.
When I've lurned me some moar python I'll consider having a stab at upgrading various things - like db.py - to python3. In that case there's MySQLdb which is depreciated. I'm sure equivical functions exist in supported libs - and maybe they won't go link-stale every 8hrs(clockwork). I suspect it's likely vulnerable too. Doesn't seem to be any sanity validation, assessment, or verification anywhere. Assuming random third parties on interwebs will provide expected input is most unwise(like having 8080 exposed leads to hoards of chinese attempting to leverage it as a proxy. accountserver.py likes that. Instant boom.)
The multiplayer facet is really the least finished part of the project IMHO. And with "modern" games it's not a feature that can really afford to be overlooked. It's gonna takes far too long for me to learn from fix it all. The amount of things I'll break on the way will be significant. Hell, I'm still failing on the preg_match to insert faction/ship selection from off the account creation form. I've working example code from the ship adjustment form too - it's only a few fields over in the save. Shameful.
Multiplayer Server Offline. Copy ony testing rig semi-funcitonal.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
-
- Hunter
- Posts: 70
- Joined: Sun Jan 19, 2014 5:02 am
Re: VegaStrike Online MMO Server
Account generation has been suspended. Using the form in it's current state will *not* result in an account you can log into. If you would like to make an acocunt before I've edited this message out, contact me via here or #vegastrike on freenode.
As the DB is just filling up with botnets filling out forms and trying to sell pills, raybans and other nonsense no-one will ever get to see as the SQL data entered isn't publicaly accessible I've swapped the creation form to point at the _test tables in order to preserve sanity in the one the game runs off. The signup form is currently acting as a honeypot gathering data on the botspam.
Thusly newly created accounts will not be viable, as the gameserver doesn't look at the _test tables, they're for me and testing(read: breaking) things.
The form can readily be made to point at the "right" table and will be done so on request. This will be done manually until I've a better system in place. I'll soon have a blocklist implimented to nish rented services for example, Then ToR. That'll dent a lot. Then anything in the DB that makes more than one account, using some commonly applied password should get stamped on... This is going to stop.
I'll find a solution to this issue eventually. An easy workaround - I suspect - would be to blacklist the p/w they are using in the complexity filter checking p/w sanity on the input form. "123456789" isn't a good password - Neither is "password" - legitimate users should be prevented from setting them anyway. This isn't a good solution however. Captcha springs to mind but most appear circumventable in a myriad of ways, if only partially - and I'd like to keep the script counts minimal. I like my systems responding instantly.
Already got a script generating reports regarding accnt creation - as that's php ergo apache's log - but I'm having issues with making the game itself log to file. Currently I get bits of data, not the extent of stdout in the screen session I'd launched it under. I've tried the obvious and to no joy.
I've also started getting errors I didn't get before migrations. When jumping to another system the server suggests the client has elected to log out. The client returns a networking error, in receiving socket(error number 9). Need to get to the bottom of that too. Nt sure what that's aboot - which side that's afflicted by. If that's .py spitting that err than No 9 may be "Bad file descriptor"(?). Can't find no logs locally or remote that suggest issues or give rise to potential cause. stdout in vegaserver delivers:
As it never used to do this I'm sure it can be made not to do it again. Just a little shoeless how at the moment. At least it saves as it jumps. This is unrelated to connections going stale, login -> jump still exhibits symptoms. It's consistent. 3/10 times after d/c attempt to login crashes local client. 1/10 of those crashes the server thinks the client is still logged in - and refuses to allow a second login. If I'm lucky it's just a permissions issue, set to allow access from localhost and it attempts to access externally or file set to the "wrong" user etc. Still not found a good way to admin users in the server, or the server generally. But think I'm getting closer to how it handles things in the source. Which should hopefully allow me to build panels to admin the live game and the DB. Hopefully.
As the DB is just filling up with botnets filling out forms and trying to sell pills, raybans and other nonsense no-one will ever get to see as the SQL data entered isn't publicaly accessible I've swapped the creation form to point at the _test tables in order to preserve sanity in the one the game runs off. The signup form is currently acting as a honeypot gathering data on the botspam.
Thusly newly created accounts will not be viable, as the gameserver doesn't look at the _test tables, they're for me and testing(read: breaking) things.
The form can readily be made to point at the "right" table and will be done so on request. This will be done manually until I've a better system in place. I'll soon have a blocklist implimented to nish rented services for example, Then ToR. That'll dent a lot. Then anything in the DB that makes more than one account, using some commonly applied password should get stamped on... This is going to stop.
I'll find a solution to this issue eventually. An easy workaround - I suspect - would be to blacklist the p/w they are using in the complexity filter checking p/w sanity on the input form. "123456789" isn't a good password - Neither is "password" - legitimate users should be prevented from setting them anyway. This isn't a good solution however. Captcha springs to mind but most appear circumventable in a myriad of ways, if only partially - and I'd like to keep the script counts minimal. I like my systems responding instantly.
Already got a script generating reports regarding accnt creation - as that's php ergo apache's log - but I'm having issues with making the game itself log to file. Currently I get bits of data, not the extent of stdout in the screen session I'd launched it under. I've tried the obvious
Code: Select all
>> /var/log/vegaserver.log
Code: Select all
2>&1 >> /var/log/vegaserver.log
I've also started getting errors I didn't get before migrations. When jumping to another system the server suggests the client has elected to log out. The client returns a networking error, in receiving socket(error number 9). Need to get to the bottom of that too. Nt sure what that's aboot - which side that's afflicted by. If that's .py spitting that err than No 9 may be "Bad file descriptor"(?). Can't find no logs locally or remote that suggest issues or give rise to potential cause. stdout in vegaserver delivers:
Code: Select all
recv returned -1
READ DATA:
recv returned -1
READ DATA: !4 EyeR9 127.0.0.14 6777
recv returned -1
READ DATA:
recv returned 0
/networking/netserver_acct.cpp:50 Got response for TCP client
g/lowlevel/vsnet_sockettcp.cpp:362 Connection closed in header
g/lowlevel/vsnet_sockettcp.cpp:286 virtual int VsnetTCPSocket::recvbuf(Packet*, AddressIP*) connection is closed
, disconnecting(eof)
tworking/netserver_clients.cpp:642 enter void NetServer::disconnect(ClientPtr, const char*, int)
*** from src/networking/netserver.cpp:437
*** disconnecting EyeR because of TCP peer closed
g/lowlevel/vsnet_sockettcp.cpp:303 void NetServer::logout(ClientPtr) : Warning: disconnect null socket: Resource temporarily unavailable <--??Issues Here??
tworking/netserver_clients.cpp:666 Client EyeR disconnected
tworking/netserver_clients.cpp:667 There were 2 clients - *** REMOVING client: 489 privateer Llama (Llama.stock), 'EyeR' 0
1 clients left in zone 1
src/networking/zonemgr.cpp:388 BROADCASTING CMD_EXITCLIENT to client #255
*** KILLED a npc '' (dead)
tworking/netserver_clients.cpp:684 1 clients left
g/lowlevel/vsnet_sockettcp.cpp:77 enter virtual VsnetTCPSocket::~VsnetTCPSocket()
Destruct called. If called from C++ this is death 137708272 (0x83542f0)BASE Destruct called. If called from C++ this is death 137708272 (0x83542f0)lose bounty mission
Destruct called. If called from C++ this is death 137861584 (0x83799d0)BASE Destruct called. If called from C++ this is death 137861584 (0x83799d0)src/networking/zonemgr.cpp:693 PosUpdate not sent (too far away) Seaxbane #402
Multiplayer Server Offline. Copy ony testing rig semi-funcitonal.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
-
- Hunter
- Posts: 70
- Joined: Sun Jan 19, 2014 5:02 am
Re: VegaStrike Online MMO Server
Account signup operational.
I've stemmed the flow of accounts generated by botnet somewhat, not had an account generated in a few days so I've set it to push into the game's DB again.
I've stemmed the flow of accounts generated by botnet somewhat, not had an account generated in a few days so I've set it to push into the game's DB again.
Multiplayer Server Offline. Copy ony testing rig semi-funcitonal.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
-
- Hunter
- Posts: 70
- Joined: Sun Jan 19, 2014 5:02 am
Re: VegaStrike Online MMO Server
Due to general lack of use over the years of it's existence, and other factors, I've elected not to renew the server lease.
If anyone would actually consider using it, I'd consider firing another instance back up.
If anyone would actually consider using it, I'd consider firing another instance back up.
Multiplayer Server Offline. Copy ony testing rig semi-funcitonal.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
User Signup Offline.
Server Health Shows old data from last snapshot before the server downed.
If you have any issues you can usually find me in #vegastrike on freenode.
-
- Hunter
- Posts: 85
- Joined: Wed Jul 30, 2014 5:59 pm
Re: VegaStrike Online MMO Server
That is...as soon as we get it working again.
Operating System: (Linux) Ubuntu 16.10 (Yakkety)
Vegastrike-taose: 0.5.1
Vegastrike-taose: 0.5.1
-
- Star Pilot
- Posts: 4
- Joined: Sun Aug 13, 2023 9:22 pm
Re: VegaStrike Online MMO Server
I am interested. Maybe we could make a fork,
throw aboard the NPC and "worldchanging in the Background" stuff, concentrate on one System with TRADE, MERCENARY&RESCUE and PIRATES.
Missions should be real Missions by Users and i have an marketingidea to get some people to play.
But this ist a Lot of Work, so we should get more programmers. Maybe the Developers semselfs are interested?
write to yusuff-supplies@outlook.de
Sivio
throw aboard the NPC and "worldchanging in the Background" stuff, concentrate on one System with TRADE, MERCENARY&RESCUE and PIRATES.
Missions should be real Missions by Users and i have an marketingidea to get some people to play.
But this ist a Lot of Work, so we should get more programmers. Maybe the Developers semselfs are interested?
write to yusuff-supplies@outlook.de
Sivio
-
- Merchant
- Posts: 53
- Joined: Mon Apr 27, 2020 1:56 pm
Re: VegaStrike Online MMO Server
The fork does exist, it's at https://notabug.org/Test_User/VegaStrike-Fork-Engine and https://notabug.org/Test_User/VegaStrike-Fork-Data
However, it was made dormant as all of us moved to another MMORPG (TheManaWorld, it has nothing to do with space). For your info, TestUser is another person and not me.
I still have on my TODO to learn how to maintain an effective fork: basically, taking useful commits from VegaStrike upstream, without the network removal commits. I have no idea how much work it would take to turn VegaStrike into an actually enjoyable MMO experience. Thus, currently, the plan from my side is "waiting until VegaStrike developers re-add multiplayer support themselves".
However, it was made dormant as all of us moved to another MMORPG (TheManaWorld, it has nothing to do with space). For your info, TestUser is another person and not me.
I still have on my TODO to learn how to maintain an effective fork: basically, taking useful commits from VegaStrike upstream, without the network removal commits. I have no idea how much work it would take to turn VegaStrike into an actually enjoyable MMO experience. Thus, currently, the plan from my side is "waiting until VegaStrike developers re-add multiplayer support themselves".