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!
Related
I'm currently developing a IIS 7 managed module, that will be distributed along with a server-side software.
How can I manage settings/configurations within the IIS module itself? For example, how can I let the user set an API-key that will be internally used by the module?
I know that in Apache or in nginx I can add settings directly in the VirtualHosts file (apache) and in nginx configuration files (nginx). I wonder if is there a "best practice" for IIS modules.
Yes there is, you can use web.config files for that, optionally you could define your own Configuration Section, but depending on how complex your configuration is, maybe using the existing appSettings section is enough.
From your module you can just read appSettings like:
How to read appSettings section in the web.config file?
and the best thing is that this includes built-in UX in IIS Manager to manage Application Settings. The bad part is that it will not give validation for your customers, nor "intellisense" to guide them through the configuration.
If you want to define your own section you can look at:
http://www.iis.net/learn/develop/extending-iis-configuration/extending-iis-schema-and-accessing-the-custom-sections-using-mwa
when you add your Schema file, in IIS Manager you will be able to use "Configuration Editor" and will give a simple UI for your customers to set that with validation, data type, collection management, etc.
I have a uCommerce package installed for my sitecore. The problem exists when you start editing template items under sitecore/templates/User Defined/uCommerce definitions/. When you restart IIS or recycle application pool (apparently this happens after solution rebuild) the template items reset their values to the fixed one. What could be causing the problem? Is there any cache mechanism which could be causing this?
update: have checked the sitecore database, the field values are being saved and stored in database properly after iis reset/pool recycly, so there is pretty much confidence that it has to do something with caching
The UCommerce DataProvider (UCommerce.Sitecore.SitecoreDataProvider.DataProviderMasterDatabase) automatically adds the templates under sitecore/templates/User Defined/uCommerce definitions at start up so they will always be reset after each recycle.
First off, make sure that you are making your changes in the Master database and not the Web database. If that is not the issue, then try the following while logged into Sitecore as an administrator:
Go to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the Sitecore cache
Go to the Master database's content editor and look at your templates
Make any changes necessary, save and publish
Do your IIS restart / application pool recycle (the latter occurs on every build)
Go back to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the cache again (just a base-case)
Go back to the Master database's content editor and look at your templates again
If the issue occurs after trying those steps, then you should open a Sitecore support ticket and see what they say. You may also want to try making a clean install of Sitecore and trying to reproduce the issue there (Sitecore Support is likely to do this as well).
The problem was that the standard values template presentation layout I have been updating was the english version. However, there was another language version set and the layout for that version was different. When uCommerce is resetting the template on application pool recycle it doesn't take into the account the multilanguage support, so the last retrieved language version of that fieldvalue is used as reset template and that different language version with different layout was used. A partial workaround is to use the same layout for all the language versions.
I am deploying a SharePoint 2010 web part that uses the microsoft .net charting tool to build charts. I need the chart handler added to the sharepoint web.configs automatically. I've been told that when you create the wsp the package can be told that when the program is installed it needs to modify the web.config to add these handlers.
I have seen a couple options out there:
-WebConfigModifications
-Safe controls
I don't know which, if any, that I should be using. I don't know for sure if this will be a first time installation for the application (we're moving sharepoint environments at the same time we are updating this. I think that it will be a first time installation on that new environment but can't be sure.)
And I definitely do not know how to implement this correctly. I would appreciate any advice.
Also it may be important to know that I do not have any privileges on the server. I can't even deploy myself.
For example, this seems like good info: http://platinumdogs.me/2009/07/08/using-the-mschart-controls-in-sharepoint-moss-2007/ Except that I can't just write to the webconfig and restart IIS. It has to be automated and not a direct edit to the file.
Thanks all!
I would recommend that you use a Feature Receiver attached to your WSP to create the appropriate SPWebConfigModification entries when your solution's features are activated. Likewise, the SPWebConfigModification entries should be removed when your solution's features are deactivated.
Step 1: Create a Feature Receiver
MSDN has an overview of how to add a Feature Receiver: http://msdn.microsoft.com/en-us/library/ee231604.aspx
Note you'll want to handle both the FeatureActivated and FeatureDeactivating events.
Step 2: Use Feature Receiver events to add or remove SPWebConfigModifications
In those two events, you'll need to programmatically add or remove one or more SPWebConfigModification entries. These affect SharePoint's web.config file, but unlike a manual edit of the config file, they are stored in SharePoint's content database. This means that if the web.config is reset for any reason (and it happens), SharePoint can and will reapply the modifications, thus preserving your changes.
MSDN has an overview of programmatically creating and removing SPWebConfigModifications: http://msdn.microsoft.com/en-us/library/office/bb861909(v=office.14).aspx
It is very important that the FeatureDeactivating event properly clean up all modifications made during FeatureActivated, or you will end up with a proliferation of duplicate config entries. This means you need to really understand how to use the Path and Name properties of the SPWebConfigModification.
This article gives a good overview of how Path and Name are combined to create an XPath expression pointing to the node to be added or removed: http://smindreau.wordpress.com/2013/06/12/finally-the-way-to-add-web-config-modifications-to-sharepoint/
Step 3: Test, test, TEST!
Lastly, test activating and deactivating your solution's feature in your local development environment to make sure everything is working properly. Note that the modifications will be applied via a timer job, so you may need to wait a minute or two to see the changes show up. Be sure the feature deactivation cleans up your modifications! (If you get into a mess in your development environment with duplicate modifications, you can always wipe the slate clean with a little PowerShell action.)
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.
I am having a problem with a Wix installer, that covers three different feature sets (Client / Developer and Server).
When Client is selected the installer does not need to perform any of the actions with IIS that are defined in components that aren't included within this feature.
On Installation I don't get a problem, as I have added a Custom Action
<!-- Only perform the IIS Configuration if we have installed the Admin Application-->
<Custom Action="SkipIISCA" Before="InstallValidate">
<![CDATA[COMPONENT_TYPE = 2]]>
</Custom>
Which is only run when the "Client" component type is being installed. The custom action sets the SKIPCONFIGUREIIS property to 1
The problem occurs when either a Repair on an uninstall is executed on the installer. It appears that IIS Configuration is being attempted when the product is being uninstalled or repaired, and the custom action does not seem be run to disable this behaviour.
Is there a good way to set the SKIPCONFIGUREIIS setting on uninstallation / repair based on a Registry Setting ?
Thanks.
Some of the properties set during an installation are stored in the hidden windows directory, c:\windows\installer - one per installation. In the log of your uninstall/repair session, you can see that cached file opened up and properties being set for the new uninstall/repair session. (Alternatively, you can find this temp file from the uninstall/repair log, and open it with Orca. In Orca, under "Property", it will show the values of any install properties saved).
Based on the above description, I bet that the property that the custom action is being set is not stored, but that the value of COMPONENT_TYPE is available (The same input that was used to set SKIPCONFIGUREIIS in the custom action).
If so, then just make the IIS configuration action be based on these properties:
<Custom Action="Your_Configure_IIS_Action" Before="InstallFinalize">
(NOT SKIPCONFIGUREIIS ) OR (COMPONENT_TYPE = 2)</Custom>
If you don't want the ConfigureIIS to happen for any feature set during uninstall/repair, then just use these properties:
<Custom Action="Your_Configure_IIS_Action" Before="InstallFinalize">
(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")</Custom>
Another thing to think about is if the original installer was at one level - e.g. a client, and the uninstall/repair is being done by someone at the server level. The component_type of the original install is stored. In that case, you might consider adding a check on how the component_type is determined (thru a dialog or some other attribute) during the uninstall/repair.