I know how to declare foreman hostgroups using the online portal but how do you make it affect a host? Also where does all the manifests/module regarding the host group go? And is there a particular format to it?
Thanks for replying in advance!
You need to set the host group on the host, by going to the hosts list (Hosts > All hosts), click Edit next to the host and select the host group from the dropdown list, then Submit. Any Puppet classes you set on the host group will apply to that host.
You can also set the host group on multiple hosts from the host list by using the tickboxes on the left, then choosing Change Group from the Select Action dropdown menu in the drop right.
Your Puppet modules go into the regular Puppet modulepath for the environment that your host is in. If your host is in the "production" environment, then this would usually be /etc/puppet/environments/production/modules/. Paths such as /etc/puppet/modules/ are usually configured in Puppet's basemodulepath and should apply to all environments.
The layout of modules needs to meet Puppet's autoloader layout, which gives a predictable structure so Puppet can find them. If you were adding an ntp class, it'd probably be in /etc/puppet/environments/production/modules/ntp/manifests/init.pp.
Once you've put your module(s) on the filesystem then you can import them under Configure > Puppet classes > Import. If they don't show up, check the syntax with puppet parser validate init.pp etc.
Related
I've understood that, in order to make IIS read a new environmental variable, I have to reset it via an administrator's command:
iireset /restart
I know that one can also restart IIS from the admin panel at server level.
More context to my complete web app setup in my previous question/answer: in brief it is a Python Flask app running on IIS through WSGI and FastCGI.
What is still surprising me is that now, if I delete a previously created environmental variable, IIS keep seeing it, even after restarting it, as done above.
Why is that possibly happening? And how should I delete the variable for IIS?
If you insist that you want to go with environmental variables (notice that you also have the alternative .env file), then you need to set them via the IIS FastCGI Settings from the IIS admin at server level for your specific application (the one you enabled via wfastcgi-enable).
Edit the specific row as said above and you'll find the Environment Variables collection under the "General" group of FastCGI Properties.
Now you can add and delete any of those variables and it will take effect immediately, without the need of any IIS reboot.
Is there a tool similar to Ansible / Chef / Puppet to manage the configuration of a single instance / machine which keeps all setting in one place?
I'm thinking of some kind of text based configuration manager where you can put your settings into text files and apply all settings by issuing one command.
I really like the way Ansible works: Everything is nicely structured in yaml files and you can configure all sorts of dependencies / tasks / templates etc..
All of the above tools offer the possibility to run the client and server part on the same machine, but all were built to deploy settings on a large number or group of machines which seems to be overkill for this purpose. Or am I wrong?
You are wrong. Those tools are totally fine also for managing your workstation, all (Chef, Puppet, Ansible) also have a mode to work without any server/master - AFAIK Ansible even has no such thing at all.
Ansible works well for this task. A method that I have found works well is to setup a default inventory file and utilize the non-ssh connection type 'local' and it takes the command
ansible-playbook -i /path/to/inventory playbook.yml
down to
ansible-playbook playbook.yml
The Setup
Setting up the default inventory file
In /etc/ansible/hosts add an entry for localhost like so:
localhost ansible_connection=local
I am currently trying to automate the process of bamboo remote agent installation and uninstallation. I have run into a problem in regards to adding and removing capabilities.
What I am trying to automate:
(The following is what I do on the bamboo server via the GUI, I want to do this on the remote agent machine via bash script.)
I install the remote agent on a VM machine, then start it up. I go to the bamboo interface and click on the newly created agent's name.
I add a custom capability type, for the key I put 'buildserver' and for the value I put the name of the agent.
I add an 'Executable' capability of type 'Command' with Executable label 'cygwin' and path 'C:\cygwin64\bin\bash'
I navigate to the git executable, and remove it by clicking 'delete.' <--- (the problem step)
what I've done.
I have looked here and found a way to automate steps 1-3 using the following "bamboo-capabilities.properties" file:
buildserver="AGENTNAME"
system.builder.command.cygwin="C:\cygwin64\bin\bash"
However I am stuck on how I would remove the git capability (step 4.) I've tried something appending something like this to the file:
system.git.executable=""
but it does not seem to do anything. Does anyone know how I would do this? There seems to be very little documentation about this online.
Thanks very much.
I never found a way to get around this, but I found a workaround. I later learned the point of removing git in my situation was to allow a shared capability that was also called git to take precedence. My workaround was to set the non-shared capability to the value of the shared capability. I am not 100% sure that this does the same thing, and I am not in a position to test it yet, but as a capability seems to be only a key-value pair I don't see why it wouldn't.... will update if anything breaks.
We are looking into Liferay with multiple tenancy for business reasons for disparate audiences. I have some questions around this. I'd appreciate some insight on the following questions:
From the question/post liferay and more instances, it seems like there are constraints around Portal properties where some are global versus instance specific. Is there any list or insight on what properties are global Liferay scoped versus instance specific?
From the post on Liferay portal instances, it seems like > The preferred way to configure a portal instance is through the Control Panel.
From talking to various people, it also seems like sharding with portal instances has some performance known issues. It is recommended to turn off sharding when using instances. Does anyone know which Liferay properties to use to turn the sharding off or if sharding is off in Liferay 6.2 by default (if so, which properties to review to confirm that sharding is off)?
Is there a limit on how many instances we can use? We may be using atleast 3-4 instances to start with. Any know known issues with number of instances?
Thanks a lot for any information on this.
Here is what I found from another source in case it helps someone:
One of the first and most important things to remember about portal properties is that they are always overridden by any settings made in the Liferay Control Panel. The reason why is that any configuration done in the Control Panel is saved directly to the database and the configuration set in the database is always read after the portal properties have been imported, thus overriding them. Once a configuration has been done in the Control Panel, that setting can never again be modified or altered by a portal property.
This does make one wonder why there are two places to make setting configuration changes and why the Control Panel trumps the portal properties file every time. The reason why this is done is directly related to your first question regarding global and scoped settings.
The portal-ext.properties file is often used to set configuration for that physical bundle of Liferay; every instance of Liferay on that physical bundle will inherit those settings, but those settings will not be automatically inherited by any other Liferay node or bundle of the same instance.
The Control Panel is often used to set configuration for that instance of the Liferay Portal; every node connecting to that instance will inherit these settings and override any values set in the portal properties, but those settings will only be inherited by other nodes connecting to the same instance.
In other words...
- The Control Panel settings are used for the Liferay instance.
- The portal properties settings are used for the Liferay bundle
- The Control Panel settings will always override the portal properties settings
This does allow some control on how to set default properties for the bundle or node, as well as to save configuration for the entire instance. As an example, you will want to use the portal properties to configure cluster settings, the database connection settings, document library connections, as well as other performance/system settings.
However, you will also be given a choice of where to configure settings such as the mail server. If you set it in the portal properties, every instance of Liferay on that node will have those settings automatically, which may not be desirable depending your goals. If you set it in the Control Panel, then ever Liferay node connecting to that instance will get those settings automatically, but the portal properties will not modify those settings again.
Now, there is a way to create an instance specific portal properties file that will have values only read by that instance of Liferay. Please note that this does complicate things even further and it may not be desirable for your goals. The following property and its definition explain how to accomplish this:
#
# Each portal instance can have its own overriden property file following
# the convention portal-companyWebId.properties. To enable this feature, set
# the "company-id-properties" system property to true.
#
# To enable:
#
# java ... -Dcompany-id-properties=true
#
# The read order will now be: portal.properties, then portal-ext.properties,
# and then portal-liferay.com.properties.
#
# Note that not all properties can have different values per company. This
# functionality is only available for legacy reasons. The preferred way to
# configure a portal instance is through the Control Panel.
#
include-and-override=portal-${easyconf:companyId}.properties
include-and-override=${liferay.home}/portal-${easyconf:companyId}.properties
The choice is yours on where you want to configure your portal settings and with the above knowledge I believe you will be able to make the best decision for your goals.
In regards to sharding, sharding is disabled by default and has to be manually configured via portal properties as well as via the database itself. This is a slightly older wiki article on how to enable database sharding support in Liferay, https://www.liferay.com/community/wiki/-/wiki/Main/Database+Sharding. For reference, here are some of the properties that need to altered:
##
## Sharded Databases
##
#
# Set the database that is to be used for the default company and globally
# used tables in a sharded environment.
#
shard.default.name=default
#
# Specify an algorithm for selecting a new shard on portal instance
# creation. Use ManualShardSelector for shard selection via the web
# interface.
#
shard.selector=com.liferay.portal.dao.shard.RoundRobinShardSelector
#shard.selector=com.liferay.portal.dao.shard.ManualShardSelector
##
## Spring
##
#
# Input a list of comma delimited Spring configurations. These will be
# loaded after the bean definitions specified in the contextConfigLocation
# parameter in web.xml.
#
# Note that there is a special case for hibernate-spring.xml and
# jpa-spring.xml. Even though both files are specified, only one will
# actually load at runtime based on the property "persistence.provider".
#
spring.configs=\
META-INF/base-spring.xml,\
\
META-INF/hibernate-spring.xml,\
META-INF/infrastructure-spring.xml,\
META-INF/management-spring.xml,\
\
META-INF/util-spring.xml,\
\
META-INF/jpa-spring.xml,\
\
META-INF/executor-spring.xml,\
\
META-INF/audit-spring.xml,\
META-INF/cluster-spring.xml,\
META-INF/editor-spring.xml,\
META-INF/jcr-spring.xml,\
META-INF/ldap-spring.xml,\
META-INF/messaging-core-spring.xml,\
META-INF/messaging-misc-spring.xml,\
META-INF/mobile-device-spring.xml,\
META-INF/notifications-spring.xml,\
META-INF/poller-spring.xml,\
META-INF/rules-spring.xml,\
META-INF/scheduler-spring.xml,\
META-INF/search-spring.xml,\
META-INF/workflow-spring.xml,\
\
META-INF/counter-spring.xml,\
META-INF/mail-spring.xml,\
META-INF/portal-spring.xml,\
META-INF/portlet-container-spring.xml,\
META-INF/staging-spring.xml,\
META-INF/virtual-layouts-spring.xml,\
\
META-INF/monitoring-spring.xml,\
\
#META-INF/dynamic-data-source-spring.xml,\
#META-INF/shard-data-source-spring.xml,\
#META-INF/memcached-spring.xml,\
\
classpath*:META-INF/ext-spring.xml
You can read more about how to implemenent sharding in the User Guide here, https://www.liferay.com/documentation/liferay-portal/6.2/user-guide/-/ai/liferay-clustering-liferay-portal-6-2-user-guide-20-en, if you are curious.
In regards to the number of instances allowed, there are no hard limits but please note that each instance will be competing for the same amount of resources and performance degradation will likely occur. This does make performance tuning even more important than normal to avoid undesirable performance.
As an FYI - from testing I found that the following properties to configure the Announcement portlet template etc. is only possible via the portal-ext.properties file and not via the control panel. So if the values of the properties are different between instances than you will need a company specific properties file.
Hope this helps!
Windows 7, 32 bit. I have added the "Group Policy Object" to the MMC with group selected as "non-administrators" (from [browse]-->Users). I have locked down the capabilities of the local machine so that non-administrators can do very little, and now I want to be able to apply this policy setting to clones of this machine. Further, I want to be able to put these settings into source control so that policy modifications can be tracked. I want the administrators to have full capabilities.
Once configured on my target machine, I have created a WIM with the Microsoft Deployment Toolkit (MDT) which solves the first half of my needs but this makes it hard to compare any changes to the policy.
I have installed the Security Compliance Manager (SCM) but this wants a baseline to start with and I do not see how to apply policies to groups with this tool. I have installed the LocalGPO.wsf tool as well and have created a backup of the local policy with the /Export switch, but when I use the MMC to change the non-administrator policies, this is not reflected with the LocalGPO.wsf when I run the /Compare against my previously exported GPO. We cracked open the LocalGPO.wsf file and at first glance it looks like it calls SECEDIT.exe which does not seem to take any switches for group policies.
Am I missing a switch on the LocalGPO.wsf that will export the non-administrator group policy settings so that I can put this into source control?
Is there another way to apply my changes to the non-administrators in the SCM? I could not find that menu item.
Are my aspirations too high to be able to update these policies in a controlled fashion?
Thanks - Steve
%windir%\System32\GroupPolicyUsers
Unhide files
or
MMC add Group Policy Object Editor -> Users Tab -> Non-Administrators Policy
Expand User Configuration > Windows Settings > Scripts > Logon; Click Add; Click Browse; It will open up the folder containing scripts. If you go up two folders you will find the folder to copy to other machines (for me it was called S-1-5-32-545).
I'd like to know the answer to this as well. I recently made a Windows 7 kiosk and I'd like to export the changes I made in non-administrators for future reference. It seems that gpresult only looks at what is applied from a domain level.