My standalone.xml resides in the repo for inclusion in the docker image. As I have no working docker on my local Windows 7 machine, I'm using a local Wildfly 14 (14.0.1.Final). I tried starting Wildfly with the jboss.server.config.dir property pointing to this standalone, but then Wildfly complains about not finding logging.properties in the same directory, so I must have my standalone.xml in the Wildfly config directory.
To avoid having a possibly outdated copy of standalone.xml in wildfly-14.0.1.Final\standalone\configuration, I created a symlink:
>mklink standalone-myapp.xml c:\path\to\standalone.xml
>dir standalone-myapp.xml
...
07.11.2018 10:24 <SYMLINK> standalone-myapp.xml [c:\path\to\standalone.xml]
However when Wildfly starts, it overwrites the symlinked file and it's not any longer a symlink:
>dir standalone-myapp.xml
...
07.11.2018 10:28 23'069 standalone-myapp.xml
Can this behaviour somehow be configured or fixed?
Update
In fact using the read-only mode (--read-only-server-config) allows to specify a standalone.xml in a directory without logging.properties. If I had know this option I wouldn't have experimented with a symlink.
I still think it's a bug that Wildfly doesn't update the file pointed at by the symlink, but it doesn't bother me anymore...
You could pull your standalone configuration from git ;) or start WildFly in read-only mode thus avoiding this overwriting (but loosing any changes you might be doing on the configuration).
Related
We are planning to utilize Spring Cloud Config for our service. Our biggest concern is that when the container starts up, it relies on github to be available all the time so that it can pull the config files. In case github is down, what is the best practice to mitigate the issue?
I was thinking of storing a local folder of the configs as a backup and configuring the application.yml to fallback to it (I do not know how).
I was going to use a Composite Environment Repositories
Please see here: Section 2.1.8
However it states:
Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment.
This means if the git retrieve fails, it does not fall back to the local component of the composite. I wish it did. Have any of you handled a similar problem? How did you solve it?
Here is a good article about best practices. However, I need a workaround for case 1: Best practices on handling GIT repository inavailability
Spring-Cloud has a configuration property to handle this issue;
spring.cloud.config.server.git.basedir = /your/config/local/fallback/directory
NOTE - If you're using a .yml file, then define the above property as
per yaml conventions.
To have a background knowledge, look at the documentation: http://cloud.spring.io/spring-cloud-static/Finchley.RC1/single/spring-cloud.html#_version_control_backend_filesystem_use
So essentially what happens here is that - as long as your application was initially able to connect to the git repository which you set up in spring.cloud.config.server.git.uri = https://your-git/config-repo.git, then on config-server/container startup, the directory you have defined in your spring.cloud.config.server.git.basedir gets created locally and by default spring-cloud clones your configurations into this directory to be available as fallback.
So whenever your git repository is unreachable, spring-cloud will pick up your configurations from this base directory.
Important things to note:
Unless you really want to re-clone the git configurations only on config-server startup alone, ensure that the property spring.cloud.config.server.git.clone-on-start is NOT set to true or is entirely not set at all - Otherwise, every time you restart your cloud-config service the configurations will be deleted and freshly cloned again and if the repository is not available at the time, application startup will fail - and you perhaps don't want that.
However, if spring.cloud.config.server.git.clone-on-start is set to false or is not even set at all (in which case the default is false), then the git repository will only be cloned on demand - hence if the repository is unreachable, spring-cloud will fallback gracefully to pick up configurations from the spring.cloud.config.server.git.basedir
Even when the application config-server (or its container) is restarted and the git repository is not reachable, you will see something like below;
No custom http config found for URL: https://your-git/config-repo.git/info/refs?service=git-upload-pack
... s.c.a.AnnotationConfigApplicationContext : Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext#3a26f314: startup date [Mon Oct 15 22:01:34 EDT 2018]; root of context hierarchy
... o.s.c.c.s.e.NativeEnvironmentRepository : Adding property source: file:/your/config/local/fallback/directory/application.properties
Notice the line:
Adding property source:file:/your/config/local/fallback/directory/application.properties
That's where the magic happens.
So if you want the spring.cloud.config.server.git.basedir to be available as a fallback even before the first startup of your config-server (and whether or not your git repo is unreachable during the startup), you can carry out the following steps;
Manually create the spring.cloud.config.server.git.basedir
From your terminal cd /your/config/local/fallback/directory
git clone https://your-git/config-repo.git while the repo is available
Ensure that all your config files/folders/sub-folders including the .git folder are cloned directly to the root of the fallback directory.
For instance, there's a tendency that git clone https://your-git/config-repo.git will clone the repo into the fall back directory as /your/config/local/fallback/directory/config-repo. You will have to copy every darn content of config-repo - including the .git folder too - out and directly into /your/config/local/fallback/directory
Start the config-server (or its container) for the first time or whenever! ......... Voila!!
In Hippo, There are two web applications packaged as war files inside a directory called webapps, a number of libraries in a directory called shared/lib, another set in a directory called common/lib, and some configuration files such as a log4j descriptor and a Tomcat context descriptor in the conf directory.
But in Heroku, I can not find the directory of tomcat to deploy these directory like the structure of Hippo (shared/lib, common/lib, conf)
Thank you
Hippo requires access to the entire Tomcat instance for setup at least. I've read through the Heroku documentation (most of it just skimmed), but I can't see that they provide that access.
However, there is possibly a second option which you may be willing to try; build Hippo in a docker image, and deploy that into Heroku:
Creating a docker container for hippo
Deploying docker container to Heroku
I haven't tried or tested any of this, so I can't guarantee it's success. But if you're limited to using Heroku, then it's at least worth a try.
Also, if you manage to get it running using docker, I would be extremely interested to know more details.
I have installed the Jabbered 15.07 on my MAC OS. After installation, I want to config it by editing the /Applications/ejabberd-15.07/conf/ejabberd.yml. I am not sure whether it is the file I should change, I searched the Internet and found that sb said the configuration is in the folder /etc but I did not found it there. In order to prove that it is the file I want to find, I open the admin interface and add a record in the "ACL" screen. And after that I checked the ejabberd.yml, but it remained unchanged. So is it the configuration file of ejabberd, if it is not which file it should be and how to configure it?
The location of the config file depend on how you installed ejabberd.
Apparently, you used binary installer, not make install, so config file is as your expected:
/Applications/ejabberd-15.07/conf/ejabberd.yml
Admin interface does not change the config file but write in mnesia database. You could configure ejabberd so that database override config file, but this is not a good practice. To make change permanent, you need to edit ejabberd.yml file.
Note: You should use latest ejabberd published version if you are starting today (15.11).
I have a freshly installed Tomcat 7 server, and I'm trying to make IntelliJ deploy a HelloWorld Spring MVC app to Tomcat.
My Tomcat home is /usr/share/tomcat7 and Tomcat base is /var/lib/tomcat7
However, when I try to run the project, IntelliJ throws an error saying:
Error running Tomcat : Error copying configuration files from /var/lib/tomcat7/conf to /home/adonis/.IntelliJIdea12/system/tomcat/Tomcat__SpringMVCApp/conf : /var/lib/tomcat7/conf/tomcat-users.xml (Permission denied)
Here is a screenshot - http://i.imgur.com/CQ3z0e1.png
Any permissions I need to set up?
Try chmod -R 777 /var/lib/tomcat7/conf/, it works to me.
Make sure that files under /var/lib/tomcat7/conf/ directory have read permission for the user IntelliJ IDEA is running from.
chmod -R 644 /var/lib/tomcat7/conf/
should help.
Also check that /home/adonis/.IntelliJIdea12/system/tomcat/ has correct permissions and owner. Could be that it was created from a different user and your current user doesn't have the rights to write into it.
If it doesn't help, download and unpack a new Tomcat installation from .tar.gz file, configure IDEA to use this installation instead.
Note that Tomcat installed using the package manager on some Linux systems has non-standard layout and permissions, and therefore will not work with IDEA.
I had the same problem and these steps helped me to Start my tomcat7 from Intellij :
I have Linux Mint 17,and Tomcat 7 which is installed using apt-get
CATALINA_HOME in /usr/share/tomcat7 and CATALINA_BASE in /var/lib/tomcat7
1- First I created a soft link which references /etc/tomcat7
cd /usr/share/tomcat7
ln -s /etc/tomcat7 conf
2- Then you have to change the access permissions of /etc/tomcat7
sudo chmod -R 655 /etc/tomcat7/
That's it.
For me, this worked for Tomcat 8 on Manjaro Linux:
sudo chmod -R 755 /usr/share/tomcat8/
I added my own user account to the tomcat7 group.
And chmod g+r /var/lib/tomcat7/conf/tomcat-users.xml
Had the same error with usr/share, dont just blindly run a command to act as magic-wand as many just tell you you run this and that on a mother-directory.
this is Linux, always some stupid thing with the permissions.
all you garra do is using chmod 666 or chmod 777 on files that are causing the error, but you need to look at those files first using ll and ls to make sure you are not decreasing some access, you may have a directory with 77x and when you do 666 you mess things up.
just gradually and one by one increase the chmod level and check whether problem goes away or not.
Sorry I didn't give you some code to fix all the problems.
This also happens to me, and I managed to solve it for Tomcat version 9, this problem is related to the configuration of Tomcat and you just need to give it permissions to be deployed.
You can use this link for more instructions.
How to change Jenkins default folder on Windows where Jenkins runs as Windows service.
I want to change C:\Users\Coola\.jenkins folder to d:\Jenkins due to lack of space on C: partition (Every build takes ~10MB of free space). I don't want to reinstall Jenkins as Windows service. I just want to change folder of existing Jenkins instance. In case of lack of global solution I could focus only on relocating jobs folder.
Thanks in advance for your help.
Stop Jenkins service
Move C:\Users\Coola\.jenkins folder to d:\Jenkins
Using regedit, change HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Jenkins\ImagePath to "d:\Jenkins\jenkins.exe"
Start service
Apparently, grams' answer works but is not preferred. In Windows software and data/configuration files are supposed to reside in different places. This should be well known to Unix guys, it is basically like having a home directory. However, the wording with regard to JENKINS_HOME is broken anyways as setting an environment variable does not help despite what is being said in the help text.
I used the procedure that is described here: http://tech.nitoyon.com/en/blog/2014/02/25/jenkins-home-win/
Basically:
Stop Jenkins service
Edit entry <env name="JENKINS_HOME" value="%BASE%"/> in jenkins.xml in the Jenkins installation directory. This will be something like C:\Program Files (x86)\Jenkins. In your case value has to be set to d:\Jenkins
Move Files from the installation directory to the new destination, d:\Jenkins, all except (some of them may not exist in a fresh installation)
jre folder
jenkins.err.log
jenkins.exe
jenkins.exe.config
jenkins.out.log
jenkins.war
jenkins.war.bak
jenkins.war.tmp
jenkins.wrapper.log
jenkins.xml
Restart the service again.
When you read Administering Jenkins you can read all options how to modify the JENKINS_HOME environment variable.
On this website you can read how to configure you Tomcat container to override the JENKINS_HOME environment variable, they advise to create the file $CATALINA_BASE/conf/localhost/jenkins.xml, with the following content:
<Context docBase="../jenkins.war">
<Environment name="JENKINS_HOME" type="java.lang.String" value="/data/jenkins" override="true"/>
</Context>
Here is the answer that worked for me: Jenkins: How to change JENKINS_HOME on Windows
And in addition to grams answer, the most important part is creating an environment variable named JENKINS_HOME with value "D:\Jenkins". Without that, on starting Jenkins it would again create the .jenkins folder in your user home folder.
I was able to change the JENKINS_HOME variable following this http://tech.nitoyon.com/en/blog/2014/02/25/jenkins-home-win/
Setting JUST %JENKINS_HOME% as windows system wide environment variable didn't have any effect!
We installed by dropping the .war into Tomcat, and could set home by just setting the environment variable JENKINS_HOME (with a service restart).