I want to use a custom project base path. As far as I understand I need to change PROJECTS_ROOT in /etc/awx/settings.py. However, nothing happens when I do... Do I need to do something to manually reload the settings.py?
PROJECTS_ROOT is set by default to /var/lib/awx/projects. Make sure you have created your preferred projects path, set it to be owned by the awx user/group and move any existing projects you've created under the default path to your new path.
You'll need to restart httpd and supervisord for the changes in settings.py to be reloaded.
Related
I'd like to edit a few ElasticSearch 8 settings (for example: network.host), but I don't want to edit /etc/elasticsearch/elasticsearch.yml directly. What I'd like to do is to add my settings to my own file and put it in an hypothetical /etc/elasticsearch/conf.d folder, do be included automatically.
This approach is widespread with multiple other software I use (Nginx, Apache, MySQL, PHP just to name a few).
ElasticSearch already does what i need with /etc/elasticsearch/jvm.options.d, but that folder is just for the the JVM options, not for ES own settings.
What am I missing here?
You can override the config path via env variables:
ES_PATH_CONF=/path/to/my/config ./bin/elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/current/settings.html
There is an old discussion about doing what you are asking about but didn't make it this way:
https://github.com/elastic/elasticsearch/issues/11362
I want to add 3 extension to nifi (nifi-encryptMD5-nar-1.0.nar-unpacked,nifi-getOperator-nar-1.0-SNAPSHOT.nar-unpacked,nifi-splitAttributeValue-nar-1.0.nar-unpacked)
I added the extensions folder in the directory /opt/nifi/nifi-1.9.2/work/nar/extensions/
then when I restart the nifi service, nifi turns off and does not turn on, when I force the start with the user nifi, nifi turns on but the extentions have been deleted from the directory /opt/nifi/nifi-1.9.2/work/nar/extensions/
you have to put *.nar packages into nifi/lib directory.
nifi will extract it automatically on startup into nifi/work folder.
As daggett says, you need to use the .nar files, not any unpacked directories.
In your nifi.properties there will be two or more properties that provide locations for NiFi libraries:
nifi.nar.library.directory=./lib
nifi.nar.library.autoload.directory=./extensions
nifi.nar.library.directory.<something>=./<yourdir>
The first is the default and contains all the basic NiFi files. It is only checked on startup and any valid nars found are unpacked in the work directory and loaded. Generally you don't want to add anything here except in test environments as it complicates upgrades.
The second is empty by default but it is scanned every 30 seconds for new .nars. These will be unpacked and loaded if possible, but only for new libraries. Already loaded libraries will not be reloaded.
This is a good location to add your validated custom libraries without having to restart NiFi.
The third and further need to be added manually to the properties file. These are loaded on startup only and useful if you have a lot of custom processors and want to keep them organized.
In your situation I'd put the .nars in the extensions folder and check the logs to see if they were loaded successfully. You'll then need a full refresh of the browser window (Shift+F5 I think) before they show up in the list of processors.
In a cluster setup, add the .nars on all nodes and verify their availability before trying to add them to the canvas or things might get messy.
I'm using phpFastCache in a frontend-application, setting the path to the server's "/tmp/" directory:
phpFastCache::setup('path',"/tmp/");
I do not want to use phpFastCache's automatically found cache-directory, because it clutters my home directory with an extra directoy for every domain through which users are reaching the application (several are connected).
In the backend I would like to display cache-statistics and be able to clear the cache. This doesn't work anymore, now that I have set /tmp/ as the cache path. Statistics show up empty and the cache is not cleared. I did configure the cache-directoy to the same "/tmp/" in the backend-application as well.
How can phpFastCache be configured to be able to achieve this?
After looking at the phpFastCache-code, I'm able to answer my own question:
To achieve what I wanted (have only ONE cache-directory, regardless of domain used; be able to list statistics and clear cache from a separate application) I had to make two config-settings:
phpFastCache::setup('path', '/path-to-my-home-dir');
phpFastCache::setup('securityKey', 'phpfastcache');
I'm setting these identically in both my frontend- and backend-applications.
This will make phpFastCache use /path-to-my-home-dir/phpfastcache as its only cache-directory.
Had I not set the 'securityKey', phpFastCache would have generated one from the current domain (in most cases), therefore my backend application would have only "seen" that part of the cache residing in the directory for the currently used domain.
Coming from a MAMP Pro background, I loved the ability to have a "base" folder (/Sites in this case), have all of my projects underneath it and set custom server names/aliases with it. With Vagrant, it looks like I can accomplish the name/alias part with vagrant-hostsupdater, but if I really did just want to have the Vagrant files in /Sites and then all of them use the same config, what's the best way to specify a subfolder disk location with those custom host names?
I'm most likely over-thinking this, have just been a sucker for GUI interfaces and would love to know how to accomplish this. Thanks as always!
Clarification
What I'm used to
I used to use MAMP Pro, which allows you to setup custom host additions with their GUI interface. So, within my ~/Sites directory, I have several different projects going on, all in subfolders. The screen shot below shows how I can set a server name and specify a disk location, all from this central location.
What I'd like to do with Vagrant
Now I do know of (and used vagrant-hostsupdater), but what I was wondering is if I can set my Vagrant file in my ~/Sites directory (which is kind of like the root of the server; since all of my projects require the same setup) and then have individual host names setup for each project - so instead of having to access a subfolder like local.dev/project-1 or local.dev/project-2 I could setup server names such aslocal.project-1.comandlocal.project-2.com` from within that top-level Vagrant file and specify the subfolder it should attach that rewrite rule too.
The reason I'd like to do this is so I only have to run one vagrant up and I can then access all of my projects from one Vagrant instance as well as only keep track of one Vagrant file. Thanks!
You need to tell vagrant what hostnames you would like to use.
Directory based hostnames
Assuming you set you would like to set your hostnames based on the directory name; you can get all of the hostnames with ruby and pass them to the hostsupdater configuration.
SITES_DIR = "~/Sites"
config.hostsupdater.aliases = Dir["#{SITES_DIR}/*/"].map { |d| d.chomp('/') }
Configuration based hostnames
Alternatively you can mock up some sort of configuration that is desirable to you and what you are trying to do and evaluate/process it in ruby within the Vagrantfile.
Normally, after we create profiles both DMGR and Node, we have folder applications under path $DMGRPROFILE_HOME/config/cells/$cellName and installedApps under path $NODEPROFILE_HOME/.
All the applications to be deployed will be put into folder installedApps. And we can also see the same contents under the folder applications above. So my question is what's the difference between them? why does the websphere application server put such apps into folder applications besides installedApps?
what's more, for example, if i need to update one file named web.xml of my deployed application war file, do i have to update file under both path above?
Thanks in advance
The applications path under the Dmgr profile contains the files that have been deployed in the admin console.
The installedApps path under the Node profile contains those files after they've been synchronized out to each node. In most cases, this will be immediately after the deployment as well.
Deploying a single file
The safest practice would be to deploy a single file using the admin console, rather than editing it in-place on the filesystem:
The downside is that you have to enter the entire path to the server-deployed file name. e.g. webapp.war/WEB-INF/classes/com/yourcompany/project/package1/YourClass.class.
If you have a typo, it will deploy, but not where you wanted, and you might not notice it until your expected changes didn't take effect.
Direct edit on the filesystem
That said, it is faster to edit on the filesystem, so we do that at times especially for like JSPs. To do that, you need to edit the copy under the Node's installedApps directory. (The location is controlled by WebSphere variable APP_INSTALL_ROOT, which defaults to ${USER_INSTALL_ROOT}/installedApps.)
web.xml
web.xml, however, is different. If you edit that in installedApps, the changes won't take effect. Instead, you'll need to edit the one in a path something like:
$NODEPROFILE_HOME/config/cells/cellName/applications/earName.ear/deployments/applicationName/warName.war/WEB-INF
Or do it in the $DMGRPROFILE_HOME and then synchronize the node (either through syncNode.sh or through the admin console).
Either way, you'll then need to restart the enterprise application.