I just compiled AzerothCore on Wndows 10 64bit, setup database, configuration files and data files (dbc, maps, vmaps, etc).
When I tried to start authserver.exe or worldserver.exe they just closed suddenly without any error or any log file created.
Fixed:
Do NOT just rename the .dist configuration files!
Copy/paste .dist authserver and worldserver configuration files then rename them and leave .dist configuration files untouched.
What was my issue?
I renamed authserver.conf.dist and worldserver.conf.dist to no .dist extension which caused the issue.
How to avoid this issue?
Do NOT just rename the .dist configuration files!
Copy/paste .dist authserver and worldserver configuration files then rename them and leave .dist configuration files untouched.
Related
I change the code in repo carbon-apimgt, and i run command "mvn clean install -Dmaven.test.skip=true" , I get a jar from target, what's next to apply this change?
Plugins directory is where we keep all the jars of components that are used in the product. Patches directory is used to track the changes done to each jar. What it does is, when you add a directory (eg: patch0001/) and add a jar to this new directory (eg: patch0001/org.wso2.carbon.apimgt.api_9.0.174.jar), this will replace the same-named jar that is found in the plugins directory.
Before this replacement, the server will first backup all the jars that are found in the plugins directory to a new folder patch0000 inside the patch folder.
At each startup, server will first apply the jars in the patch0000 directory and start replacing the jars by increasing the counter of each patch folder. (eg: patch0000, then patch0001, patch0002 up to patch9999).
This is the difference between the plugins directory and patch directory. If you replace a jar in the plugins directory, this is not a backward compatible change. However, if you replace a jar using this patch mechanism, whenever you remove the patch0001 directory from the system, this change will be reverted and the original jar will be preserved.
When I run composer install for my symfony project, my .env file is rewrote by new generated one. What should I do to save my .env intact?
Applications created after November 2018 had a slightly different system, read changes
From the official documentation
.env.local : defines/overrides env vars for all environments but only in your local machine
.env : defines the default value of env vars.
The .env and .env.<environment> files should be committed to the shared repository because they are the same for all developers. However, the .env.local and .env.<environment>.local and files should not be committed because only you will use them. In fact, the .gitignore file that comes with Symfony prevents them from being committed.
I'm trying to install Grav on Heroku following the learn.getgrav.org docs.
I've got the web app deployed successfully, however it tells me to bin/grav install.
I do that and it gives me the following output:
ERROR Missing .dependencies file in user/ folder
I do not know what to do at this point as it's happened everytime I've installed Grav.
Hope this will be solved.
Sadly this problem is all too common when copying files :(
hidden (dotted) files are not always copied.
.dependencies
.htaccss
using ls -l -a in the folder where you extracted the files originally Dowloads/grav I could see the files that were not copied to fix it
cp .dependencies .htaccss /var/www/grav/
When I install GRAV on my server each time, I always copy the Zip file to the server, unzip it in place, then remove the zip file - using this method I have never had a problem with the installing of GRAV
HTH Rich
Hi i have installed openstack-dashboard and i noticed that exists two files of configuration local_settings.py in /etc/openstack_dashboard and settings.py in /usr/share/openstack_dashboard so can you tell me the difference between them .
Thank you in advance.
The file in /usr/share/openstack_dashboard/... contains the default application settings.
The file /etc/openstack_dashboard/local_settings.py contains overrides that are particular to your environment.
You would edit the latter to make configuration changes in your environment, but not the former. The file in /usr/share/openstack_dashboard/... will be replaced on package updates/new version installs, but the file in /etc/openstack_dashboard should be preserved on upgrades.
I've the following environment: One Apache2 Webserver on an Ubuntu machine with three vhosts (one vhost per project). Those three project run all on Symfony2 (but differnt versions, from 2.2 to 2.4). Each of the projects (and its paths) have an own user. I'm deploying the projects with capifony on this server, each has an own receipt.
Sass version
Sass 3.2.14 (Media Mark)
Imagine I'm deploying application 1 to the Webserver. When the deploymentprocess comes to dumping all production assets, its writing the temporary generated sass files into the following folder:
/tmp/600d657f6ac2358f30ba6bc0ab4cd7ffb6194ced
as user1.
If I'm deploying now application 2 to the Webserver, dumping the assets would like to write into the exactly same folder, this time as user2 and the following error occurs:
An error occurred while running:
* [err :: 10.0.106.103] '/usr/bin/ruby' '/usr/local/bin/sass' '--load-path' '/srv/vhosts/myproject.com/releases/20140619124055/app/../web/sass' '--scss' '--cache-location' '/tmp' '/tmp/assetic_sassbsrcle'
* [err :: 10.0.106.103]
* [err :: 10.0.106.103] Error Output:
Errno::ENOENT: No such file or directory - /tmp/600d657f6ac2358f30ba6bc0ab4cd7ffb6194ced/assetic_sassbsrclec20140619-27927-aw8xrk.lock
My workaround currently is, to remove this /tmp/600d657f6ac2358f30ba6bc0ab4cd7ffb6194ced folder every time before deployment.
I didn't find any pathconfiguration in the capifony receipts nor in the Symfony2 config files in all projects.
Any help is appreciated.
Best,
Ramo
This has been referenced on the official assetic repository as an issue, as well. Since you can set sys_get_temp_dir() via the environment variable TMPDIR (among others), I would recommend doing that for your dump. You could base it off the current unix time, or the commit you're deploying, or a combination of the application, time, and intent. Really, anything could work. The line responsible for setting the cache location is here, in case you wanted to fork Assetic and change that, which is quite doable as well. I would suggest the TMPDIR route at first to confirm a potential fix.
Small edit, there is also this pull to semi-address this issue.