With an existing authserver and worldserver in Ubuntu 18.04, how can I add a second worldserver (realm) to their setup? Does it require a completely new CMAKE or can you just copy and paste the folders?
As you might have guessed, you need one worldserver process per every realm. So to add another realm, you need to run one more worldserver.
A worldserver needs:
its own acore_world database
its own acore_character database
the acore_auth will be shared across all realms, so you need only one of it
its own worldserver.conf file. Because of this, you have to recompile and pass a different path for the configuration file (so a different -DCMAKE_INSTALL_PREFIX)
Then you can open the new worldserver.conf and configure it with:
put a different port for WorldServerPort
the new databases (WorldDatabaseInfo and CharacterDatabaseInfo)
and of course, you can change other configurations as you please
If I remember correctly, you can set your worldserver.conf A and worldserver.conf B to share the same data files (DataDir - tip: always put an absolute path here).
Lastly, you have to update your acore_auth.realmlist table by adding the new realm and its port.
Related
I’m working on a Drupal project hosted on platform.sh.
I started to work locally with Lando but I messed things up a bit and I tried to create a second local Lando build for the same project to try some changes, keeping the fist project in it’s broken state.
The problem is that the second project seems to be using the same database as the first one.
This might be related to caching but I don’t wand to lose local database data from the first project and I’m not sure I can safely Lando pull to get fresh database data from platform.sh for the second project.
TL;DR - change the name property in the .lando.yml file in your second project.
Lando creates containers based on the name property you set up in your .lando.yml file (or .lando.upstream.yml if there's no .lando.yml file). If you created a second lando project but didnt change the name property, you end up using the same containers from the first project (which is what you're seeing). Stop lando in the second project (ie lando stop) and then change the name property in the .lando.yml file in the second project and then do lando start. Now lando should build new, separate containers for the second project based on the new name.
I'm trying to migrate my current Phabricator deployment (which is a Ubuntu VM) to a docker based container.
According Phab's documentation, I should use the following command line:
bin/config set --database repository.default-local-path /my/new/path
The command above fails with:
Usage Exception: Config key "repository.default-local-path" is locked and can
only be set in local configuration. To learn more, see "Configuration Guide:
Locked and Hidden Configuration" in the documentation.
When I try the command above without --database, it changes the local.json and successfully. However, it seems that properties in stored in DB have precedence over properties defined in JSON file. Therefore, the change made to JSON file has no effect.
If this is not a bug, how do I change repository.default-local-path? If it is bug, is there any workaround?
I don't think "locked" configuration options are ever meant to be set at the database level. This value should be provided in the local config.
Assuming that you have a value set in the database that is interfering with your local config, I'd say that is a bug. The easiest workaround that I know of is to unlock the config option by editing phabricator source. What you need to do is as follows:
Unlock the config option. To do this, change the source code from setLocked(true) to setLocked(false) on line 25 of PhabricatorRepositoryConfigOptions.php.
Set a value for repository.default-local-path in local.json as you already managed to do with bin/config set (leaving off the --database argument)
Delete the database value with the following command: bin/config delete --database repository.default-local-path
Once everything is set correctly, you can revert your change to PhabricatorRepositoryConfigOptions.php which will restore the option to the locked state.
Can someone tell any way to deploy different web.config on different EC2 instances with in same deployment group.
Scenario: We have few entries in the config that will be different on different instances. So need some way to update based on instance.
Create a script to make the necessary changes to your web.config and then use the hooks section of your app.spec file to run the script before install on your deployment. https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html
I actually took the approach of storing my web.config files for each environment in an S3 bucket. As part of the CodeDeploy Deployment group process, it would download the config file from the S3 bucket in the After Install hook. This way you can build the application once and push the same application files for each environment. This also separates the configuration of the application from the actual code so that the development team doesn't need to know things like connection string values, etc...
Problem description:
I have multiple alfresco installations (development, testing, production) of one project.
I need to copy files under Data Dictionary folder (Scripts, Templates, Web Scripts) from one to another in one direction (development -> testing -> production).
Current solution:
I copy files manually via webdav, which is annoying and unreliable (I can forget to copy some.).
Desired solution:
I'd like to have I tool, which will copy changed files at my command, what they are ready for the next step. I had an idea, that it could internally use a Git repository with branches for each installation, being able to fetch the files from devel and push the files to testing and production. This way (with Git) it could also support reverting changes.
It looks like a quite common problem, but I wasn't able to google something about it, so I'm asking here. Does such a tool exist or is there a better way of managing multiple repositories?
If you have a brand new installation of your development/testing/production Alfresco instances, you could simply migrate alf_data dir content, that contains by default db, indexes, content-store, backup files. If you need, you could migrate the "shared" folder too, or at least some files from the shared folder as could be some Alfresco customization (custom scripts or similar). Here is the link that helps with migration steps:
http://wiki.alfresco.com/wiki/System_Migration
Otherwise, if you need only to move a folder from Data Dictionary, or a set of documents, you could use ACP in order to achieve that. Here is the wiki for doing this: http://wiki.alfresco.com/wiki/Export_and_Import
You could do this via FTP. When your want to deploy new changes, you can go with manual client like FileZila to download changes from Dev, then upload them to test.
But you can also automate FTP, so that it can run a scheduled check if there are new things on, say, dev and push them to test.
If you use Git for source control, you could also do this via git-ftp. Hold a copy of Data Dictionary in your source folder, then add some sort of pre-commit check, which will see if you changed any of those files. If you did, on commit it will push the change to dev and test.
I think Relication service AF is suitable for you.
http://wiki.alfresco.com/wiki/Alfresco_Community_3.4.a#Replication
I have an application written in ASP.NET and using EF. I want to make a copy of the live database, have my application point to the copy, and be able to run the application against it as if it is live...but making updates to the copy.
I know I can manually copy the database and manually update the web.config files...but I'm wondering if there is a better, more automated method for achieving this with VS 2010?
Also, if there is anything I need to know about setting up a live/dev version of a database while using EF4.
You can switch the ConnectionString to point to the live or development database.
One way is to have different web.config files for debug and release builds.
Check out Web.config Transformation Syntax for Web Application Project Deployment
From my experience,
Setup 2 database connection entries in your config file, name one backup and leave the other ones name alone. Point your backup one to the backup db and when you want to run the backup, just change the names of the entries so the backup one is the actual name and the live one is named anything else.
Also, as for setting up different db versions - I'd just be careful that you don't update live by mistake!! and I've found it best to track changes to the db structure in a sql file so the live can be updated if needed or the backup can be rolled back if changes are made