Jump to content
TrinityCore

Thulium

Members
  • Posts

    50
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Thulium

  1. This looks like a repost of the topic below with a different repack.. Same advice as before, compile it yourself if you want support on these forums. Or check the appveyor links in this topic:
  2. Hi Pallam, It's better to report this to the issue tracker on Github: https://github.com/TrinityCore/TrinityCore/issues That's where most of the dev's are :-)
  3. I beg to differ, the reason the libraries tend to run out of sync is because the OS keeps itself updated and (as much as possible) security hole free. A better practice would be to have a 'staging/test' server which you run with the SAME version of the codebase as you have on your 'live' server. On that server you run the following 3 steps on a daily basis: - Stop MySQL/TC servers - Update OS packages - Restart MySQL/TC servers If you then run into this issue do the following: - Recompile TC on your 'test/staging' server - Test it - Update OS packages on 'live' server - Update TC on 'live server' And if you can't/don't want to do that, you can install the packages I've mentioned in my previous post, as they are compiled on a kept-current installation of Debian 8 Jessie.
  4. Hi all! I've created a script that will generate a data package for your server and added the instructions on how to use it in the post. I've just added it to my build environment, so it will be ready for use tomorrow! Cheers!
  5. Hi ruben381, First of all, make sure that you have your distribution fully updated. Normally the distribution maintainer keeps development packages (you'll need for building software) in sync with the binary packages containing the software. E.g. on Debian: apt-get update apt-get dist-upgrade apt-get autoremove apt-get clean This will update/upgrade all packages in your installation to the latest version available. After you've done that, make sure you install all the development packages required to compile TC. All of them are named in the Wiki, you can recognize them by the '-dev' suffix. Then follow the instructions to compile the server, perform all other setup tasks and you should be good to go. Shameless plug: Alternatively, install the packages I've built for Debian, they work with the current stable version of Debian:
  6. @Lorac: I can comment on the RAM usage on Linux systems. I'm currently testing a script to generate the maps and package them in a nice little zip file for me. I'm running the extraction tools on a LXC container with 2 GBs of RAM and 2 cores. Works like a charm! :-) @Flavia: If you really have difficulties compiling the server, you can always try reading: The main topic is Debian packaged versions, but Nay linked pre-built Windows binaries.
  7. That was my bad, I changed the text to reflect the correct name, but the actual link was pointing at the internal hostname. I fixed the link, try again :-)
  8. Hmm... Weird, check http://repo.element-networks.nl/trinitycore-recipes.tgz
  9. I took a look, but I take it you would like to have the original uncompiled git source in those packages? My current setup doesn't really allow for this. It does the following: - Maintain a local copy of the repo (the 'meta' script that builds trinitycore runs 'git pull' before compiling) - Build the software according to the build recipe I defined - Package the software according to the package recipe - Push the resulting package to the repo This allows me to save a lot of disk space (I only have 1 copy of the source per branch), and it *should* be possible to redo any older builds by checking out that version in git. I'm using a script a colleague made, I will link it in the post once he posted in on Github (it's on his todo-list). So that part of this setup I cannot share, as it is not my work. However, I'm cool with sharing the recipes I made for the build script (see attachment). But I do ask that if you make improvements/changes to let me know. So I can incorporate them in the scripts I use. I also just updated the build script to look for the correct version of the TDB when the source files mention it ;-) trinitycore-recipes.tgz
  10. Hi Symax, This is caused by sharpened security requirements of newer versions of APT, I've seen similar messages in Debian Unstable (which runs a version of APT close to Ubuntu's current). I've created a stronger key, but I need to do some more to make it work. I will continue with this tomorrow or Wednesday. In the mean time you could try running with Just as a side-note, I'm not sure whether these packages will work on Ubuntu, unless the names and versions of all dependencies are similar of those in Debian Jessie. But if you can let me know, I will amend the post with that information! Edit: oh, btw, I missed that question, what kind of sources would you like to know/have? I've only followed the original compilation instructions :-) Cheers!
  11. Hi Doukas, Please make an issue for this on the issue tracker: https://github.com/TrinityCore/TrinityCore/issues Also, there is no 'latest version', there are only revisions on dates... ->
  12. Looks very helpful, I've got my eye on an issue I wish to check and see if I can make a fix for it :-)
  13. That looks like it could work, I'll give it a shot :-)
  14. Hi Keldo, Check my first and second posts in this topic, it notes that you must have different ports.
  15. If I understand correctly, you can log in on the authserver, but you cannot connect to the worldserver? Do you run the authserver on the same machine as the worldserver? If so, you need to be able to do the following: I make the following assumptions (to help you translate the config to what you need): Authserver and worldservers are on the same machine Server IP: 10.1.1.2 Authserver port: 3724 Worldserver3.3.5 port: 8085 Worldserver2.4.2 port: 8086 Connect to the 10.1.1.2 on ports: 3724, 8085 and 8086, you can test this with the telnet command (open it in cmd). telnet 10.1.1.2 3724 telnet 10.1.1.2 8085 telnet 10.1.1.2 8086 If these commands do NOT result in 'Connection refused', it's working. (I don't know how Windows shows you this, I don't use it that often) Have the realmlist.wtf file set to that host In the realmlist table in the DB have the following: +----+---------+----------------+--------------+-----------------+------+------+------+----------+----------------------+------------+-----------+ | id | name | address | localAddress | localSubnetMask | port | icon | flag | timezone | allowedSecurityLevel | population | gamebuild | +----+---------+----------------+--------------+-----------------+------+------+------+----------+----------------------+------------+-----------+ | 1 | Worldserver3.3.5 | 10.1.1.2 | 127.0.0.1 | 255.255.255.0 | 8085 | 0 | 2 | 8 | 0 | 0 | 12340 | | 2 | Worldserver2.4.2 | 10.1.1.2 | 127.0.0.1 | 255.255.255.0 | 8086 | 0 | 2 | 8 | 0 | 0 | 8606 | +----+---------+----------------+--------------+-----------------+------+------+------+----------+----------------------+------------+-----------+ Both realms should appear in your client, however, I do not know if the WoW client will show incompatible realms as online. But you should be able to log in on the compatible version.
  16. I think I know where your problem is. You want to run multiple worldservers, however, you run (because of the difference in versions) multiple authservers as well, right? NOTE: I'm not sure if the WoW client is capable of 'finding' the auth server if it's on a different port, but you could test that. Your problem is as follows: You have 2 authservers running: You have 2 worldservers running: Worldserver 1 is realmID 1 (it has to be, if that server is working) and is configured as such in the realmlist table in the auth DB Worldserver 2 is realmID 2 (in the worldserver.conf), but is configured as realm 1 in the realmlist table in the auth DB for authserver 2 I'm not sure about the compatibility between the 2 versions of trinitycore, but the setup I made in my earlier post *could* still apply, like so: worldserver1 is configured to be realmID 1, runs on port 8085 and these settings are in the reamlist table of authserver 1 worldserver2 is configured to be realmID 2, runs on port 8086 and these settings are ALSO put in the realmlist table of authserver1. Exactly like how I posted it earlier. Nevertheless, always make sure that the following points are checked: Realmlist table contains the SAME values as in the worldserver.conf for: realmID, which would be 1 if you have 1 worldserver (and unique if you have multiple worldservers that share accounts) IP:port, which has to be unique for each worldserver
  17. Hi guys, I've included packages for the 'master' branch in the repository for you to play with! :-) but, do note that these are NOT done yet! Configuration is NOT complete (currently I've packaged the config files for the 3.3.5 branch) bnetserver config is NOT included worldserver config is 3.3.5 (I'm not sure if it's compatible) Database script might or might NOT work I will build a 'master' branch server when I have the time, but in the mean time, feel free to use these packages, but please leave a reply in this topic if there is something I missed (or to save me some time setting this up ;-) )
  18. If enough people want this, I could add that to my repository as well :-) EDIT: I'll add it later today, would you like to test it? Follow the instructions in my other post, but use the following package names: trinitycore-server-master trinitycore-tools-master trinitycore-database-master I can run a compile job now, but I can't build an actual server until later today :-) EDIT2: Compile job is done, I've added a reply to the other topic with some more info
  19. Just a note, I've changed the DB package to be based on TDB_full_335.62_2016_10_17 now. (I updated this earlier, but that was too soon :-) ) P.S. is there any check I can do (before compiling) to see which version of the TDB is required? Then I might be able to make this more seamless!
  20. Hi Cyber, Do you wish to share the same account data over the servers? If so, you have to edit the 'realmlist' table in the authserver's database to include a second line. Mine looks like this: +----+---------+----------------+--------------+-----------------+------+------+------+----------+----------------------+------------+-----------+ | id | name | address | localAddress | localSubnetMask | port | icon | flag | timezone | allowedSecurityLevel | population | gamebuild | +----+---------+----------------+--------------+-----------------+------+------+------+----------+----------------------+------------+-----------+ | 1 | [REALM1] | [EXTERNALIPHERE] | 127.0.0.1 | 255.255.255.0 | 8085 | 0 | 2 | 8 | 0 | 0 | 12340 | | 2 | [REALM2] | [EXTERNALIPHERE] | [LOCALIPHERE] | 255.255.255.0 | 8086 | 0 | 2 | 8 | 0 | 0 | 12340 | +----+---------+----------------+--------------+-----------------+------+------+------+----------+----------------------+------------+-----------+ As you can see I have 2 realms, one is hosted on the same server that runs the authentication server, and it's reachable on port 8085. The other realm can also be hosted on the same server, but you can also host it on a different server in the network. Do note, it MUST always use a different port if you want to be able to reach it over the Internet. And do setup the firewall to make sure both servers can be reached on their respective ports. Does this help you on your way? Cheers!
  21. Hi Keldo, Maybe the following topic is interesting for you :-) It saves you the compiling time, and the repository is updated on a daily basis. Also, if you run a Debian Jessie server, it comes with some configuration in place to help you manage it using the normal system controls. Cheers!
  22. I can shine some light on the security aspect of the PATH variable, in short: The PATH variable is where your shell searches for commands to run and generally speaking the default directories are only writable by system admins. This means that the chances of you running a seemingly innocent command ends up wrecking your system. However, if you choose to accept the above risk, you can edit ~/.profile with the following line: PATH=/dir/to/be/included:$PATH This will add /dir/to/be/included in your PATH variable. - Shameless plug: But, you could also install these:
  23. Hi Folks, As mentioned in a later post, I no longer play WoW and decided to not port the trinitycore packages to Debian 11 'Bullseye' which was just released. I have discontinued builds and removed the packages from the repo. Thank you all for using the packages in the past few years and all of the feedback I received! Please check the 'Rolling your own' section on how to set this up for yourself! :-) Cheers! == Original message == Hi folks, Having issues compiling? Don't want to wait for an hour to compile a new server? Want a steady stream of updates? Well then, you came to the right place! With the following instructions, one can install their own TrinityCore server using pre-compiled packages. The current state of the 2 branches is: - 3.3.5a: fully functional and installable using the instructions in this topic - master: Still WIP, the packages are compiled and in the repository, but still need to be tested and validated against the installation instructions. Not compiled automatically. == Background == There are 3 packages, server, database and tools:The database package will also install MariaDB from the default Debian Repository Server package: pre-compiled version using the instructions provided on the TrinityCore wiki. Date and commit-hash are included in version tag. By default this package will also install database, but it is possible to run the database on a remote server. And it will not overwrite any configuration files in place without asking. Database package: Contains TDB335.62 with all the database updates provided by the commit. Also contains a slightly modified auth_database (which has to be setup with the provided script), so you can control the server while it's started without console (in order to run it as a service, details below). Tools package: contains the extractors, so you can run them on your desktop with the client instead of uploading a copy to the server. I also included a script that will queue all the commands you need to generate a data package for your TC server. This package isn't supposed to run on the same system as the server (because it would require you to upload a complete WoW client to your server). The packages come with a default configuration to support service control by SystemD. A few details: /opt/trinitycore - server files and data files /var/log/trinitycore - server logs /var/run/trinitycore - PID files See https://github.com/TrinityCore/TrinityCore/issues/18069 for more info on how and why == Update frequency == These packages will be recompiled everyday at midnight, compiling/uploading takes about an hour per tree, so expect fresh packages: - 3.3.5a: around 01:30 AM CEST - master: not compiled automatically (per 2019-09-09) The script will automatically download the latest TDB version if it is updated in the source files. If there are any changes with the configuration files (new options added etc.) I will add them as soon as I can. == Installation Instructions == This instruction will help you setup a TrinityCore server on a Debian Buster server with it's own local MySQL server. If you require a seperate MySQL server, please adjust where needed. All packages provided are only tested on Debian Buster stable (with updates). !!! WILL NO LONGER WORK ON DEBIAN VERSIONS BELOW 10 !!! It is in your best interest to read the entire instruction first before installing! Install a server with Debian Buster and log in on it You don't need anything except the basic install! Add the following line to /etc/apt/sources.list deb http://repo.element-networks.nl/ buster main Add the repository key for package verification wget http://repo.element-networks.nl/public.gpg -O - | apt-key add - Update your package lists apt-get update Install the server 3.3.5a: apt-get install trinitycore-server3.3.5-en master: apt-get install trinitycore-server-master-en NOTE: This command will install the TrinityCore server and all it's dependencies (including a MariaDB server) If you want to run a seperate database server, run this command with '--no-install-recommends' to skip the installation of the database package. FIRST TIME ONLY: Run the following script to setup the databases setup_database.sh If you run the database on a different server, run the script on that server. Also, change worldserver.conf and authserver.conf accordingly! Extract the MAPS, MMAPS and VMAPS using the extractors. Pro-tip, if you have a (fast) Linux (gaming) desktop, do the following: Install the trinitycore-tools3.3.5 package on your desktop with the WoW client. apt-get install trinitycore-tools3.3.5-en Go to your WoW client folder and run the script cd /to/my/wowclient generate_data_package.sh After extracting all the maps, mmaps, vmaps and dbc's it will ask you the following question: # Your data package is in /to/my/wowclient/trinitycore-data.tgz # Would you like this script to apply it on your server? y/N If you select yes, it will ask you where to upload the data package See https://trinitycore.atlassian.net/wiki/display/tc/Linux+Server+Setup for all the details surrounding the extracting process. Start the server! systemctl start trinitycore-authserver.service systemctl start trinitycore-worldserver.service You can control the server using the following command: telnet localhost 3443 Username: admin Password: ChangeMeNOW! Change the password for the admin account: .account set password admin NEWPASSWORD NEWPASSWORD Create a new user .account create USERNAME PASSWORD Press Enter again to log out Set your client's realmlist to your newly installed server GameClientDir/Data/enUS/realmlist.wtf Note: enUS could also be enGB if you have a European version of the client Start your game, log in and enjoy! == Upgrade to Debian 10 Buster == When upgrading my system to Debian 10 (Buster) I ran into an issue where my MariaDB server was no longer starting properly. In order to fix it, do the following: Make a snapshot of your current machine (and always make backups!) Before upgrading, run the following command, this will upgrade some MariaDB internals to the current version you have running. If you are already up to date, the script will say so. No need to run it with --force mysql_upgrade -u root -p Upgrade your system to Debian 10 via the usual way (lots and lots of guides already on the interwebz, find one) When you run your server on LXC, please enable Nesting and restart the LXC container again. After starting the server, check if MariaDB is running, and run the upgrade script (step 2) again to update MariaDB's internals again. == Updating == Updating the server to a newer version is very easy, I do it using the following script: #!/bin/bash # Upgrade the TrinityCore server to the latest build # Stop running server systemctl stop trinitycore-worldserver.service # Upgrade packages, change the packagename if you wish to run the 'master' branch apt-get update apt-get upgrade trinitycore-server3.3.5-en trinitycore-database3.3.5-en -y -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold' # Start server systemctl start trinitycore-worldserver.service == Feedback == Any feedback is appreciated! I have been running my test-server with this setup for a few days now and it is still alive and kicking. However, my userbase is quite small (5) and I would like to know if the current way of updating is doable. Thoughts, feelings, emotions? == Rolling your own? == Want to compile it yourself, but make it easier? Don't trust me? Need custom patches? No problem! Below are the recipes I use for the build script I use to generate the binaries and the packages. They are still only suitable for Deb based distro's, but feel free to roll your own! https://github.com/Thulium-Drake/trinitycore-recipes
×
×
  • Create New...