Bloggers recientes

Shannon Chang

Staff
4 Mensajes
24 de abril de 2015

Lauri Hiltunen

1 Mensajes
23 de abril de 2015

James Falkner

Staff
107 Mensajes
23 de abril de 2015

Neha Goyal

3 Mensajes
23 de abril de 2015

Bejond Shao

Staff
1 Mensajes
22 de abril de 2015

Martin Yan

Staff
12 Mensajes
22 de abril de 2015

Adam Victor Brandizzi

Staff
4 Mensajes
20 de abril de 2015

Vernon Singleton

Staff
4 Mensajes
14 de abril de 2015

Meera Prince

20 Mensajes
12 de abril de 2015

Juan Gonzalez

Staff
3 Mensajes
8 de abril de 2015

The right tool for the job? Chapter 1: Instances

Company Blogs 18 de marzo de 2015 Por Olaf Kock Staff

Liferay comes with so many features that it's hard to judge when a feature is a good solution for a given problem. I'd like to shine some light onto some of these features and common misconceptions about them because it's easy to abuse them for purposes for which they're not well suited - despite making the impression they might.
CC BY-ND 2.0 by S. Benno

Today I'm starting with Liferay Instances.

TL;DR? Skip to the last paragraph, giving the common "wrong problems" that instances are used to solve. While they are a great feature, they don't necessarily solve all of the problems they get thrown at in the expected way.

What is an instance?

If you go to Control Panel / Configuration / Portal Instances, you'll find the list of available instances and can add more. A new instance is introducing a totally separate data area - you'll have a new user database, new content, new sites etc. They have nothing in common with the other instances that you have in the portal. Nothing? Well, they share the same application server - so at least the portlets and plugins are shared, and naturally the maintenance intervals & downtime. But, on the data side: Nothing.

As you would expect, Liferay starts with a single instance that is used to handle all requests. Only if you actively introduce a second instance, you'll use multiple instances. The reason for this is that instances are detected through the server name: If you connect to the server depicted above with spaceprogram.liferay.com, the server will serve with the content of the second instance. All hostnames that can't be associated will be handled by the default instance.

This is called multi-tenancy. You may have multiple portals on a single application server. Great, isn't it?

Using Multiple Instances

Now assume you're providing services for multiple customers. You have your first customer's portal running at customer1.example.com in the first instance and you'd like to add customer2.example.com as a completely separated portal: Neither the content, nor the user administration should interfere with each other.

On first sight, you'd easily just introduce another instance named customer2.example.com and populate it with the required data - done. Two customers, two instances.

That was too easy, wasn't it? Where's the shortcoming?

Well, you'll end up with two instances with different features - one is more special than the other

Different features?

The first instance on Liferay is a special instance: It enables you to administer the application server (garbage collection, reindex search index, show memory consumption), install new plugins, access marketplace, etc.

Compare this part of the Control Panel of the first instance

with the same part of the second instance: You'll easily see that all of the server administration, application installation etc. is only to be found on the very first instance. (I promise that I'm logged in as Administrator on both instances).

As long as your first customer is not more special than your second one (and allowed to administer infrastructure for all of them), you might want to limit yourself to a particular different use of instances:

Make the first instance a purely administrative instance, e.g. administration.example.com. Then add all of your customer's sites as secondary (tertiary etc) instances. You'll end up with n+1 instances. The default instance should only have a few administrative users, while the other instances have whatever those instances need.

Now your first instance's administrators can maintain the whole site while your customer's administrators can't install server side plugins and maintain them - great, because the plugins are always available to all other sites, and they might not even know whom they share the server with. Imagine your customer1 to update customer2's theme... (see comments below)

Commonalities and Differences

Remember, all instances still share the same server. If one of the instances is really busy, the performance of the others might go down with it. If one requires downtime for updating a component, the others will go down with it. If one of the customers needs a specific plugin to be deployed, all of the customers will get it.

On a firewall level: If one of the instances needs access to a particular backend system (of customer1), connections to it will originate "at Liferay", thus no firewall can detect which instance the connection is coming from.

Separating instances

What happens when - some time in the future - you want to separate the instances from each other? If you follow my suggestion to have an administrative instance as first instance, life is (relatively) easy: Create a copy of your whole portal (all instances) and delete all the unused customer's instances from each of the instances. You'll end up with two portal servers with an administrative instance (which is a copy of each other).

Everything well? Or the wrong problem or the wrong solution?

Shiny, huh? But do instances solve all of your problems?

They can easily simulate to solve them. But they can also trick you into believing that they're a good solution. More often than not they aren't. Let's look at some shortcomings and issues that you should be aware of:

  • You'll have to administer each Instance as if it was a new portal: User Management, Single Sign On, User Profiles, Groups, Roles, Templates, ADTs, everything. If you update any in one instance, they won't be updated in the others. This might be what you expect, or it might be doubling your work. Typically it's some of both.
  • All instances share the same plugins (and their versions). If your customers use plugins that contain business logic specifically for them, this business logic might accidentally be published on other customer's instances. Themes and Hooks are shared between all instances as well - don't select your customer1-theme for the sites of customer2. Check the comments: You can limit your theme to specific instances
  • If one of your instances is really popular and draws a lot of traffic (enough to slow down the site), the other instances will also suffer performance and your customers might not be happy if you can't quickly serve their few web visitors.
  • If you need to cluster one instance, you must cluster all of them. Liferay's caches need to be dimensioned properly to serve the commonly requested content for all instances.
  • Some of Liferay's content types (e.g. ADTs, Web Content Templates) execute server side code. When these are done inappropriately, they might make it possible for customers to access other instance's data. You'll need to trust the individual Administrators with permissions to edit these content types to not do harm to others.
  • Instances always assume that you can predetermine the host names that users are using. You should not make your administrative site available to the internet as "the default" when you don't know the host. Thus there's some extra work that IMHO requires a webserver in front of the appserver. But that's good practice anyway.

Did I forget something?

Did this discourage you from using instances? It shouldn't - it just should help you make an informed decision when you consider using them and how.

Overriding JSPs from multiple hooks - promising the cure

Company Blogs 17 de marzo de 2015 Por Olaf Kock Staff

One message that I have to give out in trainings doesn't fail to stun the students: When you deploy multiple hooks that override the same JSP in Liferay, you will first get undefined behavior and later end up with a damaged installation.
CC BY 2.0 by David Goehring
When you are installing applications from Liferay's marketplace you don't even have control over the JSPs that these apps change. And there seem to be certain hotspots that everybody wants to change - experiencing a conflict is merely a question of time.

Out of the box you'll have to deal with this behavior on an organizational level - there's no safeguard, no tool, no oversight - not even logging - in Liferay. Yes, I admit: this is a shortcoming of the platform. And it puzzled me so often that I finally took action to solve this problem. After all, you can change any behavior of Liferay, right?

What's the problem?

Let's say you want to override /test/view.jsp. When you deploy the hook, Liferay will rename the original file to /test/view.portal.jsp and use your patched one as the new /test/view.jsp. Great - now you can include the original file from yours and add your changes (if you want). Undeploy of the hook reverses the process. Smart, right?

One problem now is that this is a one-step process:
CC BY 2.0 by David Goehring and yours truly
If you deploy a second hook overriding the same file, the mentioned procedure will repeat. In that process the original /test/view.jsp (later /test/view.portal.jsp) will be overwritten and lost forever. Now undeploy both hooks and no  /test/view.jsp is left. Did I tell you that deployment order of hooks is not guaranteed, so you never know what you end up with?

And the solution?

Due to the nature of hooks (deployment order not guaranteed), the solution must tie deeper into Liferay and an ext-plugin is in order: We need code that is running before the first hook is deployed. This will replace your original hook deployer with a safeguarding version - first testing for conflicts and denying deployment if there is any duplicate overridden JSP. Granted, it will not magically make everything work, but it will keep you from destroying your installation.

Check out the code on github - fork and send pullrequests: Beware, it's currently meant as a proof of concept. Please test, try & pound on it out on your platform & version. I have built and tested on 6.2 EE SP8, but due to the nature of the code it is probably working well on other versions and on CE with little or no change at all.

Due to being an ext-plugin this can't be made available on marketplace, but we can try it out here (and in future articles if necessary).

About the code

I've started with patching HookHotDeploymentListener.java - but when you look at that class you'll see that it's not meant to be extended. For all future upgrades this would have resulted in three-way-merges. And I hate three-way-merges. Thus I've changed the implementation to a wrapper. The new CheckingHookHotDeploymentListener just does its sanity check before delegating execution to the original HookHotDeploymentListener.

If you have your own ext-plugin already, you might want to move it in there, because I also need to override portal-ext.properties in order to replace the original hotdeploylistener: Each file (like portal-ext.properties) can be overridden from only one ext-plugin and the odds are that you want to change the same file anyway - portal-ext.properties is among the very popular hotspots for ext-changes.

Please give feedback and help testing it on other versions. There might be a distributable result if you help. And based on the twitter feedback (and the stunned faces in training) there seems to be a demand for this functionality.

I already have a portlet that shows the list of rejected contexts to the control panel and will share it soon. Find it on github as well. It will add itself to the Apps section of Control Panel. Until then you'll have to stick with the log output. For testing just create a few hooks that modify a new, currently unknown jsp and deploy them all - see if you can break it.

Update: Oh, look at this

Dragging and dropping portlets

Company Blogs 18 de febrero de 2015 Por Olaf Kock Staff

This is a repeat post - same topic as in July 2013, when I've solved exactly the same problem on Liferay 6.1. Now it's time to update the solution to Liferay 6.2. But I am ahead of myself: What seems to be the problem?

Liferay offers various layout templates that determine how the portlets are arranged on the page. When you build a Liferay page, you can drag&drop portlets on the page, according to the layout template. But it's not always obvious, where you can drop portlets. And if you happen to not know the layout template that has been chosen for the current page, you might not even know that there's another column or row. Especially when you have one of the multiple row layout templates.

Try it: Choose one of the layouts from that screenshot on the right, then drag&drop portlets: The only indicator you have is the blue line. Nothing indicates the additional row that still might be available unless you happen to hover over it.

Wouldn't it be nice to have all of the columns well visible - at least while you're dragging & dropping portlets? Like this "Hello World" portlet that's currently being dragged (note that the dotted style doesn't really show in this scaled image. Yes, I should have chosen a different border style. View that full image to see the unscaled version, or use your CSS imagination):

In 6.1, all the required CSS was available in the default theme, thus you only needed some javascript to add to the page. In 6.2 I couldn't find the CSS any more, thus I've had to add some custom rules. Do this in your theme, or just adhoc on the page (Site Administration/Pages/Look&Feel). You will need CSS like this:

And in addition, the same javascript that I mentioned in that old article still works (and is required as well). To try it out immediately, just go to "Site Administration/Pages/Javascript", then paste this code:

That's it, you're set: To persist the settings and have them available always, add these few lines to your themes and from then on even your inexperienced page maintainers will always easily identify the drop zones for portlets.

If you wonder what I'm doing when I'm travelling by train - this is an example. And as I am able to "make things look different" rather than "make things look nice", you might want to post some nicer CSS fragments as comment to this article.

Oh, and fyi: I've filed this as LPS-53664 so that there's a chance for it to be fixed soon - or at least for 7.0. I'll just have to find some time to do it yet again, on master. And, thanks to Daniel, there's also a CSS-only version that I've missed when I ported the 6.1 solution:

The Learning Curve, Chapter 6 - Java Web Development

Company Blogs 18 de febrero de 2015 Por Olaf Kock Staff

Are you new to Liferay? Found Liferay and want to know what it can do for you? Or are you with Liferay and still remember the time when you were new and unexperienced? Where did you come from and what was the biggest problem you faced? Can you ever learn enough? And how do you keep up with the current trends and new features?

A platform as big as Liferay spans several technologies and areas of best practices that are beneficial to know of. Nobody can know everything - there's always a learning curve. At the beginning, it's quite steep. Some argue that it's flattening the more you know. Some argue that it gets steeper: The more you know, the more you know what you don't know.

I'd like to give you pointers to resources that are available to you, in order to learn about Liferay, resources that help you avoid steep detours, when there are flatter direct connections. This is meant to be (eventually) comprehensive but I'm sure that it will never be complete. It's just what I remember while I write this article and the follow ups (yes, there are more, already drafted)

Today's Target Audience: Developers, new to Liferay

Java Web Technology

You new Developers will have to know some things about the internals of an Application server. Don't worry, not the implementation, but the Servlet Specification (which assumes that you know Java). In a Java Application, you typically deal with a lot of different classloaders - no difference in Liferay, although this is mostly abstracted away. In some random cases it's coming back at you though.

Where to learn about the Servlet Specification? The spec is going back quite far - it's been updated a few times, but I can't even remember how I learnt it back when I did. I'm relying on suggestions in this article's comments on what resources to recommend (and why). I know there are trainings offered, you can even get certified. IMHO nothing beats experience. So even after you've read a book or been in training: You want to get your hands dirty and actually use that knowledge in practice. (and while you're at it, it's probably good to learn the basics of JSPs). After all, a typical plugin to Liferay starts as nothing else but yet another web application on the same server.

Having some experience in Java and Java Web Development is the precondition to take Liferay Developer Training 1, where we help you map that knowledge onto the portal world. From a comparison of portlets to servlets, JSR-286, through an introduction of service builder and the Liferay API and into extending Liferay through Themes, Layout Templates, Hooks and Ext plugins, you'll have some time to learn the basics of everything - hands on - and can ask your questions to an experienced trainer. Check the schedule for the next available public trainings in your area.

This training also covers most of what's required for becoming a Liferay 6.2 Certified Professional Developer. Add some experience and routine and the certification should be a breeze.

Choosing and learning Frameworks

Did I really just mandate knowledge of servlets? Well, knowing them really makes it easy to transfer the existing knowledge to portlets. But do you want to develop application logic in servlets, or in portlets that are nothing more than the Portlet-Spec implementation? Most likely not.

There's a lot of frameworks for you to choose - but even then: To debug your code and understand application classloader problems, experience with raw servlets sometimes brings you a long way solving problems, or just understanding answers that you get on random places on the internet.


CC BY 3.0 (by Oliver Widder, geek&poke)

Liferay does not mandate any UI technology or framework for you to use. You should pick one of the existing frameworks - they're all good and have different pros and cons. Liferay Portlet MVC? JSF? Vaadin? Spring (portlet) MVC? All fine. Any that I've not named here? Probably also fine - there are too many frameworks to name them here and compare them in a single blog post.

If you're looking at Liferay's implementation, you'll find plenty of JSPs as well as Liferay's MVC portlet and some use of Struts. This, however, does not imply anything for your own applications and portlets - if you're embarrassed to see Struts in use: Don't worry - there's not a lot of it and you don't get in contact with unless you specifically customize existing functionality implemented in struts. Liferay is agnostic to the framework you use in your extensions and plugins. Choose whatever you're most familiar with. If you're not familiar with one framework: Check back with your team. Or just pick one. SRSLY - it's your choice.

More?

Planned for next chapters:

  • Training
  • The search engine of your least distrust
  • Asking questions on the community forums and other platforms.

For more "Learning Curve" tips, check the previous chapters (listed below, under "Related")

Community Meeting in Wien

General Blogs 27 de enero de 2015 Por Olaf Kock Staff

Ich bin mal wieder auf Reisen - und zwar in Wien. Und welche bessere Gelegenheit Land und Leute kennenzulernen gibt es, als ein Liferay Community Meeting (oder Radio Liferay Hörertreffen)?
Hofburg, Wien CC by-nd 2.0 by R. Halfpaap
Es gibt keine Agenda, aber mit Liferay wahrscheinlich ein gemeinsames Gesprächsthema. Anmeldung erbeten (dann kümmere ich mich um Platzreservierung und Getränke) per Kommentar unter diesem Blogpost (bevorzugt), email an olaf punkt kock ät liferay.com oder tweet an @olafk. Bitte so früh wie möglich und hoffentlich nicht weniger als 24 Stunden vorher.

Wir treffen uns am Dienstag, 3. Februar um 19 Uhr im Bierteufl, Ungargasse 5.

Die ganz Schnellen können sich auch noch für das "Mastering Liferay Fundamentals" Training am 2.+3, Februar anmelden - Anmeldeschluss für das Training ist morgen, Mittwoch der 28. Januar.

English summary:

We'll have a community meeting in Vienna/Austria. Identify date/time/location above and register (by commenting on this blogpost) if you intend to come and want me to pay for beer.

Radio Liferay Episode 48: James Falkner on Release Plans and the 6.2 CE GA3 release

Company Blogs 20 de enero de 2015 Por Olaf Kock Staff

  A short Inbetweenisode on the release of 6.2 CE GA3 with repeat guest and Community Manager James Falkner. During Devcon James promised the release for the 15. January - while I stated that this release date was wishful thinking. Now we actually hit the promised release date for the first time known to both of us. Enough reason to get together and talk about the underlying cause and intents.

We're talking about general release practice and the plan that was put together last October, how Liferay CE will be delivered and how we're preparing to meet the promise. There's a 6 month release plan for new CE releases - and there will continue to be only one updated version of CE, e.g. once 7.0 is out, there won't be any more updates to 6.2 CE. If you need long term stability and support you should shoot for an Enterprise Edition subscription. This ensures your support for 5 years from release.

We also talk about the next release dates, how to get issues scheduled for that release (hint: Get votes on the issue, talk about it). Also, you get new ideas and features into the next release by rolling the drum for your idea - file an issue and do some marketing for it. This way it will float to the top and get recognized.

James has a quite thorough blog article about the content of 6.2 GA3 which contains quite a lot of fixed issues and - as is typical for maintenance releases - no new features.

To keep up to date on what to expect for Liferay 7.0, keep an eye on the milestones (coming out every 2 months) and Jorge's blog articles about them.

Follow @RadioLiferay, @schtool (James) and @olafk (me) on twitter.

You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to  http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

Radio Liferay Episode 47: Chema Balsas and Emil Öberg on Themes and Frontend Development

Company Blogs 19 de enero de 2015 Por Olaf Kock Staff

  Another Devcon conversation - make sure not to miss this event next year! I grabbed Chema Balsas, Software Engineer at Liferay Spain, and Emil Öberg, Consultant at Monator Technologies, a Liferay Partner Company in Sweden. This is a three-way conversation with Chema Balsas and Emil Öberg that we had during Liferay's Devcon 2014. Chema had a Theme-Workshop (sorry, no recording) and Emil a presentation on Rapid Frontend Development, so it made sense to talk to both of them as their experience overlaps. Speaking of experience: Chema is a Software Engineer in Liferay Spain, Emil is a Consultant at Monator Technologies, a Liferay Partner Company in Sweden.

We're trying to bridge the gap and discuss visual topics, e.g. themes, in an audio format:

  • the qualities of Liferay
  • UX (user experience) and UX guidelines
  • Building themes
  • How to start new theme projects
  • Emil's github repository
  • The problem with people like me doing frontend design
  • SASS, LESS
  • New themes coming to marketplace
  • Disabling Bootstrap and the future plans with it
  • Best practices on editing/creating themes, how to update servers and test
  • Sublime, Webstorm, Brackets
  • Developing a Toolchain, ROI
  • Upgrading themes to new versions of Liferay (see also Episode 38)
  • and probably more topics that I forgot to add to these shownotes.

Follow @RadioLiferay, @jbalsas, @emiloberg and @olafk on twitter.

You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to  http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

Radio Liferay Episode 46: Thomas Schweiger on Coffee

Company Blogs 18 de diciembre de 2014 Por Olaf Kock Staff

  The nerdiest topic so far: I'm speaking to Thomas Schweiger, german national barista champion 2010-2012. He was sponsored by our german partner Prodyna to prepare coffee during this years Devcon and Portal Solutions Forum Germany.

We talked about

  • What do you need to do to become Barista Champion?
  • Can you describe upfront what your coffee will taste like when you prepare it?
  • Importing coffee, roasting, drying, grinding and preparing
  • Latte Art (learn it by just listening to this episode):
    • Foam the milk to be a homogenous liquid - stop adding air at 30°C, then roll around the foam to get microbubbles. The really hard stuff is to determine when to drop the milk under the coffee's crema and start drawing images with the foam on top.
    • Find Latte Art tutorials on Youtube (or find out what it actually is and what pictures people actually do)
  • Shoutout to Wolfram Sorg, from Prodyna Sales, who is teaming up with Thomas
  • Did you know you can be a coffee consultant? Thomas is. He's consulting on coffee farms, cafés and barista training.

Follow @RadioLiferay and @olafk on twitter.

You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to  http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

Radio Liferay Episode 45: Bryan Ho on Design and Ray

Company Blogs 15 de diciembre de 2014 Por Olaf Kock Staff

  I had a short meeting with Bryan Ho, Lead Graphic Designer at Liferay - With that role it's obvious that we're bridging the audio/visual gap again: A very visual topic in an audio only podcast. But if you're not driving while you listen to this podcast, you can click the links from the shownotes and browse through the archives.

Apart from being the creator of the Radio Liferay Logo, Bryan is the creator of "Ray's intergalactiv adventures". You can check out this series at https://www.liferay.com/ray.

We talked about

  • The history of Ray:  He is an "old" mascot, has been around on the very old website
  • Bryan started to get involved with Ray for a T-Shirt contest in 2010 and continued to draw him
  • How Ray's intergalactic adventures were started (Shoutouts to Paul Hinz and Martin Yan)
  • At Devcon Bryan  created a lot of variations on Ray "on demand". You can find several of them on the flickr stream from that event.
  • Luckily, Bryan keeps Ray around, for example on community T-Shirts, even though the cartoon series is currently on hyades.
  • And other things that the design team works on (Website, Events, improve overall visual appearance)

Here's Ray listening to Radio Liferay:

Follow @RadioLiferay, @thebryanho and @olafk on twitter.

You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to  http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

Radio Liferay Episode 44: Stian Sigvartsen on Social Apps Proxy

Company Blogs 11 de diciembre de 2014 Por Olaf Kock Staff

  This is my conversation with Stian Sigvartsen, winner of the Marketplace App contest with his Social Apps Proxy (Link) and well known member of the UK Liferay usergroup, working in Devon and quite a lot with Liferay. Our paths cross quite often, but we finally found some time to talk about Stian's award winning app which basically takes all the boring stuff out of OAuth integrations into Liferay

He did a great job of explaining the background and solution in audio. Here's what we talked about:

  • Social Apps Proxy enables you to integrate content from other social networks into your portal.
  • It's working through OAuth, basically taking over all of the dirty work of authentication, leaving the actual integration works for the implementor
  • Stian's sample app on github (Link): Getting twitter mentions with 10 lines of code
  • What problem does OAuth solve? Comparing OAuth with a Valet Key.
  • Linking Liferay's identity to twitter's (in this sample)
  • How the social apps proxy works: An application just uses it as HTTP proxy, does not care about identity and is happy to get the identity automagically taken care of
  • Social Apps Proxy on Marketplace
  • Supported Versions of Liferay 6.1 to 6.2 and OAuth 1.0a to 2 to be extended
  • Microservices
  • All Code is to be open sourced soon, contributors are welcome.

Follow @RadioLiferay, and @olafk on twitter.

You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to  http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

Radio Liferay Episode 43: Brett Swaim on Application Performance Monitoring

Company Blogs 5 de diciembre de 2014 Por Olaf Kock Staff

  I'm talking with Brett Swaim, Principal Consultant at Liferay US, on application performance monitoring, horror stories and things to avoid. Brett is dealing with a lot of customers. He's one of Liferay's go-to resources for performance tuning and monitoring. Brett had a presentation on DevOps Best Practices with Liferay, Logstash, Kibana, Elasticsearch, and New Relic  at Devcon (among other symposiums and events). If you missed it or just want the audio summary (both were my motivations to talk to him), we're talking about his experience, using one of the projects (an unnamed one) as an example.

This is a short conversation as we didn't have a lot of time in between different appointments, but we've committed to making this a series of episodes on similar topics - and more in depth.

We talked about

  • Application Lifecycle and Performance monitoring, New Relic  (used as a sample here), Compuware , AppDynamics. Or check the Gartner Quadrant
  • If you can't host in the cloud, you can use the same strategies that Brett is talking about with on-premise solutions
  • How do you know your application is slow?
  • ELK-Stack (Elasticsearch, Logstash and Kibana)
  • adding page load times to Apache Logs
  • It matters where you measure from: Internal network, external network.
  • Default configuration of Liferay - memory, garbage collection and other JVM settings
  • You can have too much memory in your JVM
  • Liferay's Whitepapers have starting points, you shouldn't use them as your final settings.
  • ...and you'll actually need to measure for yourself in order to find your number...
  • CDN setup and its results on high volume site
  • Be proactive. You'll find bottlenecks before your users do.

Follow @RadioLiferay, @Brett_Swaim and @olafk on twitter.

You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to  http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

Radio Liferay Episode 42: Zsigmond Rab on Enterprise Support

Company Blogs 4 de diciembre de 2014 Por Olaf Kock Staff

  At Devcon, I took the opportunity to meet several people - stay tuned for several more episodes during the rest of this year. For this episode, I spoke with Zsigmond Rab. Zsigmond is Lead Engineer, Technical Support & Trainer at Liferay Hungary. This is a short and informal tongue-in-cheek talk about support-related issues.

We talked and joked about

  • The structure of the Hungarian Support teams
  • How bugs unexpected features are handled
  • How to make sure that these don't show up again in the next version
  • Fixpacks, Hotfixes, Servicepacks
  • Other worldwide support teams

You might or might not know that Liferay's business is built on Enterprise Edition - and specifically on the support services that we offer here. This is what keeps the new versions coming. This episode is meant to give you some information about the procedures that happen when you (as a customer) file an issue for Liferay support. Compared to the actual internal workflow, this is simplified, but gives sufficient insight. If you want more details, please comment.

Follow @RadioLiferay, @zsigmond_rab and @olafk on twitter. You can also friend (or unfriend) Zsigmond ;)

You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to  http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

The Learning Curve, Chapter 5 - Community Resources

Company Blogs 23 de noviembre de 2014 Por Olaf Kock Staff

Are you new to Liferay? Found Liferay and want to know what it can do for you? Or are you with Liferay and still remember the time when you were new and unexperienced? Where did you come from and what was the biggest problem you faced? Can you ever learn enough? And how do you keep up with the current trends and new features?

A platform as big as Liferay spans several technologies and areas of best practices that are beneficial to know of. Nobody can know everything - there's always a learning curve. At the beginning, it's quite steep. Some argue that it's flattening the more you know. Some argue that it gets steeper: The more you know, the more you know what you don't know.

This is chapter 5 in a series of blog articles. See below this article for links to the other chapters.

Top 10 resources, lazy linking

Back in August, when I published chapter 4 of this series, I announced chapter 5 to be about Community Resources. In the meantime (actually, also quite a while ago), James has done a great job putting exactly this together, so I won't repeat him, just point you to his article Top 10 ways to keep up with the Liferay Community. Follow all his links and suggestions, then come back here.

11: But wait, there's more

One more resource though, which has been released (in beta) since James wrote his article: Our new documentation home on dev.liferay.com went live and you can find a lot of relevant information there. This site is meant to replace most of the documentation that you currently find on www.liferay.com - most specifically the Wiki, which got a bit outdated.

Note that you can see a lot of "Edit on github" links on dev.liferay.com: You can contribute and send pull requests without ever installing git or understanding the details of distributed version systems. Just click the link, edit and send in your suggestions.

12: Meet & Greet

Another additional item, directly from the current symposium season: Meeting the community is awesome. I've been lucky to have the opportunity to ruin my voice in several locations around the world (it's typically been really noisy) and all the conversations were extremely inspiring. I've learnt a lot, got lots of ideas and met interesting people - and I got the same feedback from many others. As I've said multiple times, I'm quite lucky to be able to say that events like those are actually work. From personal experience I can tell you that it's even more awesome once you made yourself known to the community, e.g. in the forums or here in the blogs. Having some reputation (and a recognizable portrait photo) and being recognized for your contributions over the time is an even better conversation starter than distributing free drink vouchers ;)

I tell you that to tell you this: Don't miss next year's event season. It's a great way to get and share ideas, knowledge, experience and feedback.

That's it?

Of course not. You'll find several personal blogs, Google+ and other resources about Liferay. Typically linked from all over, so it shouldn't be too hard to find them.

Learning is a personal experience. We have resources for the reader, the listener, the in-person-education-learner and the watcher. Some even in multiple flavors. Whatever your preferred way of learning is, you'll be able to find it. Whatever way you want to do to gain reputation or increase your knowledge: Do it. Whatever I've been missing: Add pointers in the comments. I might continue or update the series in future - for now I'll put it on hold.

And thanks again for all the inspiring conversations during the many events this year. Keep it up.

Radio Liferay Episode 41: The 37000ft overview of staging with Máté Thurzó

Company Blogs 17 de noviembre de 2014 Por Olaf Kock Staff

  Another first: This week's guest Máté Thurzó presents a brief 37000ft overview over Staging. Yes, this is literally 37000ft - we both were lucky to be invited to the North America Symposium 2014 and had the same flight back. Yes, this episode has been recorded 11277m over the atlantic ocean on the flight from Boston to Frankfurt, and it's also a first time that you see me use imperial units voluntarily.

We talked about

  • The problem that staging solves
    • "Workflow" for a whole site
  • What's new in staging in Liferay 6.2?
  • Staging in custom portlets
  • How LAR import/export relates to staging
  • Local vs. Remote Staging
  • The new staging UI: Visible Progress, Background processing
  • Performance rule of thumbs: "it depends" - I don't give the numbers here. Listen to the conversation to find out what it depends on.
  • Staging through multiple stages
  • The future of staging (in 7.0, available in the current milestone)
  • The effect of customer feedback on the future of staging. Hopefully you gave your feedback at Devcon, where Máté was attending to get more feedback. This episode should have been out by then; sorry, postprocessing took a while longer than anticipated.

Follow @RadioLiferay, @matethurzo and @olafk on twitter

Again, shoutout and big thank you to Auphonic for postproduction help. This time I really made them work. If you want to compare the result to the actual recording - let me know and you'll get a snippet of the raw file which they de-noised!

You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to  http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

Securing Liferay Chapter 4: More lockdown

Company Blogs 13 de noviembre de 2014 Por Olaf Kock Staff

You probably know the basic installation instructions for Liferay Bundles: „unzip and run startup.sh“ - with this you get to a working Liferay installation in a minute. It will run with all defaults - which might not be what you want in production.

This is part 4 of a series. Start with part 1 for "Introduction, Basics and Operating System Level", continue with part 2, "Liferay's configuration", part 3, "Port issues and http/https" and come back here. You might also want to check if more chapters are already available.

What to have in production

Browsing around the web, I see recommendations for tomcat's "manager" application all over. Yes, it's convenient. It also opens you up to attacks if that's available from the web. Whatever administrative UI you have installed on your production server, you might want to uninstall - or at least firewall to be available from specific networks only. This not only includes tomcat's manager (or related interfaces) but also phpmyadmin or whatever you use to maintain your database. I'd expect that this is not necessary to mention, but sadly it is.

If you rely on these components to be available, at least protect them with Apache (see chapter 3) and block access unless it's coming from trusted networks.

File access

In chapter 1 we set up Tomcat and changed the owner and permissions on the various files. You can extend this and look at the "soften" and "harden" options of the service starter script. As long as you don't expect any new deployments, it's good practice to have nothing but tomcat's temp, log and work directory writable by tomcat. Keep in mind that some of Liferay's "data" folder also needs to be writable, if you didn't change the locations of document library or lucene search index.

In addition, you might want to run your server within a java sandbox. For the server this will be really hard to achieve. As far as I know there's no policy file template that you could use as a starting point. However, there's help: You can run Liferay with a security manager, so that it runs plugins within a security manager. The plugins will have to be prepared for this, but you can mandate it for the applications that run on your server. See the Marketplace Developer Guides for more information on enabling security manager in plugins, called PACL.

Updates to tomcat

Patrick Wolf commented on chapter 1: Why not use your Linux distribution version of tomcat and install Liferay as a WAR archive on top of it? This will give you all updates to the appserver, while you have to maintain Liferay on your own. It will also solve logrotate issues, run as an unprivileged user by default etc. - And he's right. I've documented how to use the bundle just because it looks like everybody is using it and thought that these instructions are understood as "relevant" for this situation. The proper way to do it is what he suggests. You'll get your distribution's updates to tomcat with this. And as a side effect, Logrotation typically has also been implemented. Keeping your filesystems from overflowing is somewhat security related.

For EE customers, there's also an option to get a supported version of Tomcat. For users of other application servers: Keep an eye on your product. As this is outside of Liferay, we kindly ask you to keep overview over your platform yourself.

The installation of a WAR distribution of Liferay is well documented in the User's Guide (here for tomcat)

Updates to Liferay

if you're on Liferay EE, Liferay Cloud Services has some nice UI to keep you informed about updates that you can install. This way you're not missing out on any available fix - general improvement or security issue. Administering a web application should always mandate to keep it up to date. On EE you will get security advisories automatically. On CE you should subscribe to the Community Security Updates.

SSO & LDAP

You might wonder why I'm listing SSO under security, not under general installation tipps. Well, there's one really neat aspect on a system composed from SSO, LDAP and Liferay: The user's passwords are never known by Liferay, thus they can't get lost in case any appserver or Liferay security issue would allow access to the underlying hash values.

Network and beyond-scope

I think IDS (Intrusion Detection Systems) and similar firewalls are out of scope for this blog series. You'll know if you need them - and then it's typically not because of Liferay but because of your overall security policy. I'll not cover all aspects of your security - still: pay attention to who has physical access to your server

Future Plans

Will there be more? The more input I get, the more I can add and update this series. Security isn't a state, it's a process. Potentially there's no limit to how long this can go. Watch out for future Radio Liferay episodes on DevOps and other related topics.

Securing Liferay Chapter 3: Port issues and HTTP/HTTPS

Company Blogs 7 de noviembre de 2014 Por Olaf Kock Staff

You probably know the basic installation instructions for Liferay Bundles: „unzip and run startup.sh“ - with this you get to a working Liferay installation in a minute. It will run with all defaults - which might not be what you want in production.

This is part 3 of a series. Start with part 1 for "Introduction, Basics and Operating System Level", continue with part 2, "Liferay's configuration" and come back here. You might also want to check if more chapters are already available.

8080? I want 80!

In Chapter 1 we kept tomcat running on port 8080 and I promised that this will be mitigated later. Now is the time. Apart from port 80 we'll also cover port 443 for https access, but let's go step by step:

In order to bind to a port below 1024, an application on Unix must run as root or gain those privileges in some other way. I've already commented that this is a very bad idea for a process that is connected to the internet. In case there's any security issue that can be exploited remotely, you're toast as it's trivial to gain root access on your computer.

For this reason (and some others) I like to run a proper webserver in front of tomcat. Let's take Apache httpd for this chapter. Substitute with the one you are most familiar with. I'll abbreviate it as "Apache" for the rest of this chapter.

Apache drops the root permissions after binding to ports 80 and 443, so effectively it will not run as root. This is a trick that is easy if you run native on the operating system, but hard for a JVM process. Win: We're answering requests on port 80 without running as root. Fail: Now Apache serves our content, not tomcat - they'll need to be connected. Several options are available for this purpose

HTTP vs AJP

Apache offers mod_proxy and mod_jk (among others). They differ in the protocol that is spoken between it and tomcat. mod_proxy (to be exact: mod_proxy_http) communicates through http, while mod_jk (also to be complete: and mod_proxy_ajp) communicate with a binary protocol, named AJP.

I'm a big proponent of AJP, as it covers all of the default expectations that you have for this purpose. Assuming that you're using your distribution's Apache and you've installed mod_jk, here's what you do:

Configure some workers.properties that are pointing to your tomcat's AJP-connector. Where's that? Check your conf/server.xml file in tomcat. The default is port 8009. For the purpose of this documentation, I'm assuming that Apache is running on www.example.com, while tomcat is running on tomcat.example.com.

workers.properties:

for me, this file is /etc/apache2/workers.properties, as the next snippet refers to it.

ps=/ 
worker.list=tomcat1 
worker.tomcat1.port=8009 
worker.tomcat1.host=tomcat.example.com 
worker.tomcat1.type=ajp13 
worker.tomcat1.lbfactor=1

Now, how does this get into Apache?

You'll most likely have some VirtualHost configuration in Apache anyway for the server that you're building. Here's some pseudocode for general Apache configuration, as well as for the virtual hosts. On Ubuntu the next snippet might go into /etc/apache2/conf/liferay-settings.

ServerSignature Off
ServerTokens ProductOnly
TraceEnable Off
FileETag None
Options -Indexes
JkWorkersFile /etc/apache2/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel error
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories +ForwardURICompatUnparsed
NameVirtualHost your-ip-address:80
NameVirtualHost *:80
NameVirtualHost your-ip-address:443
NameVirtualHost *:443

and a snippet from /etc/apache2/sites-available/default

<VirtualHost _default_:80>
        ServerAdmin webmaster@example.com
        ServerName www.example.com
        DocumentRoot /srv/www/
        ErrorLog /var/log/apache2/error.log
        CustomLog /var/log/apache2/access.log combined
        Options +MultiViews
        JkMount /* tomcat1
        JkMount /  tomcat1
	JkUnmount /static/*
</VirtualHost>

What does this do? Every request that gets to Apache's default virtual host will be forwarded to tomcat. The only exception is that requests to www.example.com/static/* will still be handled by Apache (see the JkUnmount line).

Achievement unlocked: We're answering on port 80 but still run as the unprivileged user that we've been used in chapter 1.

https anyone?

What about https? Well, not much to change. Configure Apache like you would for https anyway, add the same JkMount instructions to the virtual host. With AJP you're set: Tomcat/Liferay knows that you're communicating on https, knows the ports, host names etc.

I don't go too much into the setup of a proper https server - a lot of recommendations have changed with the issues that surfaced lately. Just so much: You might want to check your setup for the recent issues. ssllabs.com is one of the sites that offer free instant testing.

Keep your private key under tight control, get a certificate for your key, set up the virtual host and you're set: https is ready.

Should I force https?

If your site contains data (or uses passwords) that should be protected, and you offer https anyway, I believe that it's a good idea to force https on anybody. Won't this generate significant overhead on the webserver? Measure!

With the setup that we have so far, you could easily add a https-terminator into the game, or have https completely handled by your Apache. You'll need to figure out by yourself what fits your environment and load profile.

If you want to force https, just implement unconditional redirect on the VirtualHost for port 80 to the https VirtualHost, like this:

<VirtualHost _default_:80>
        ServerAdmin webmaster@example.com
        ServerName www.example.com
        DocumentRoot /srv/www/
        ErrorLog /var/log/apache2/error.log
        CustomLog /var/log/apache2/access.log combined
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

And if you know HSTS, you might want to add one line to your VirtualHost on port 443:

<VirtualHost _default_:443>
        ServerAdmin webmaster@example.com
        ServerName www.example.com
        SSLEngine On
        # further https options omitted
        ErrorLog /var/log/apache2/error.log
        CustomLog /var/log/apache2/access.log combined
        JkMount /* tomcat1
        JkMount /  tomcat1
	JkUnmount /static/*
        Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
</VirtualHost>

Naturally, this requires the required modules to be installed: Header and Rewrite* are not in the Apache core, but readily available.

What about http/https mixed mode?

This is quite a popular question. Why not use http for users that are not logged in, but use https as soon as they log in. Until recently I publicly stated that This! Does! Not! Work!. The main reason is that you'll definitely miss some setup and, sooner or later, leak some data, cookie or other information.

HSTS app iconRecently I found a neat workaround that limits the amount of configuration errors. As soon as the next Internet Explorer is available and adopted, it might even be a viable option (all other browsers support it). You can conditionally enable HSTS just when a user logs in to Liferay. More information in the Liferay HSTS app that yours truly has published on marketplace. With this, the case for mixed mode turns a bit towards a mixed mode that I don't totally reject.

Check the description in the app for the options that it opens. Note that you'll still make your life easier with the single line I give above. But if you drive up the download numbers and give reviews for that plugin, that is very welcome ;)

Other options: mod_proxy_http

Another quite popular configuration is to communicate http to tomcat. This has some drawback, e.g. all requests to tomcat will originate on Apache, tomcat will have no idea where in the world they came from. Also, tomcat will believe that its hostname is tomcat.example.com - this is true, but in a properly firewalled network, this address will not be available from the outside. We'll need to hack this with a few more options:

If you prefer proxying through http, look up ProxyPreserveHost On, which will make the original hostname, www.example.com, available to tomcat. Also, you want to configure Liferay's portal-ext.properties to have the proper ports. Check this in the original portal.properties that you already read during the previous chapter:

#
# Set the HTTP and HTTPs ports when running the portal in a J2EE server that
# is sitting behind another web server like Apache. Set the values to -1 if
# the portal is not running behind another web server like Apache.
#
web.server.http.port=-1
web.server.https.port=-1

(you probably want to set these ports to 80 and 443)

All of this is not necessary with AJP - everything is readily communicated to tomcat.

https and mod_proxy_http

With mod_proxy_http you'll need more work to let tomcat know that you're communicating https. You'll typically terminate the https connection on Apache and just forward to tomcat through http. For this reason tomcat doesn't know about the encryption - it never sees any encrypted connection.

A neat hack that you can use here is: Introduce another HTTP connector on tomcat that you'll purely use for proxy requests from your https virtual host. Add the secure="true" attribute to let tomcat know that the original requests on this connector have been encrypted. The relevant part of your server.xml might look like this:

    <Connector executor="tomcatThreadPool"
               port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" URIEncoding="UTF-8" />

    <Connector executor="tomcatThreadPool"
               port="8081" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" URIEncoding="UTF-8"
               secure="true"/>

Now you only need to make sure that nobody but the encrypted VirtualHost on Apache does connect to 8081 and tomcat assumes that requests coming in on 8081 have indeed been encrypted - but doesn't need to handle any encryption itself.

Future chapters

...coming soon...

Remember: This is not the only - and not the complete - truth. Please add your experience (and disagreements) in the comments

Securing Liferay Chapter 2: Liferay's configuration

Company Blogs 31 de octubre de 2014 Por Olaf Kock Staff

You probably know the basic installation instructions for Liferay Bundles: „unzip and run startup.sh“ - with this you get to a working Liferay installation in a minute. It will run with all defaults - which might not be what you want in production.

This is part 2 of a series. Start with part 1 for "Introduction, Basics and Operating System Level", then continue here and check if more chapters are already available.

What Configuration?

As we've covered the Operating System Basics and the appserver with Liferay is running as an unprivileged user, let's check Liferay's configuration. Some of Liferay's configuration is done on the UI layer and gets persisted to the database. As the UI options naturally are spread all over the administrative UI, let's put this to the side for now. There's another resource that provides quicker ROI:

portal.properties

First of all: As a motivated System Administrator, you should have access to portal.properties already. It's well packaged (so that you don't accidentally change it) in Liferay's WEB-INF/lib/portal-impl.jar. Go ahead, extract it and keep it around. Then read it - yes: I actually recommend to read it. It's roughly 10.000 lines of configuration options, commented optional configuration as well as a lot of documentation for the individual configuration options.

You can also get hold of a HTML rendering of this file on the documentation server if you don't like the formatting of portal.properties. It might be easier for the eye to read.

Do you need to read it line-by-line? No. There are large sections, that you can easily "page-down" through. But if you have a broad idea of the content, you'll get a lot of ideas about Liferay's configurability. In fact, you might find features that you never knew to be in Liferay. I have learnt a lot about Liferay's features this way. And I have found some convenience options, that I'll add to every instance that I maintain.

(If you read it now and come back once you're done: I promise that I'll be still here when you come back)

...

...

...

...

...

...

No, really. Go read it.

...

...

...

...

...

...

...

What now?

Wasn't that an amazing read? What did you learn that you didn't know of?

Now that you've been through the file at least once, you might want to go through it again - now searching for specific values. Try the following search terms (and again, some of the places you can page-down through). Note, by design some are only partial words (e.g. in order to search for "security" or "secure", just search "secur")

  • password
  • encrypt
  • hash
  • restrict
  • secur
  • auth
  • timeout
  • servlet.filter
  • deploy
  • register
  • https

And when you're done with this, you probably want me to name the settings that you must set in order to get the "secure" certification for your configuration. Right?

Well, unfortunately I won't and I can't: What adds security for one ruins a feature for somebody else. You're totally required to do your homework - I can just point you to the options that you have. I think I forgot to mention earlier that security is hard work, but you probably knew this. This is part of the work. (oh, and please suggest your favorite settings that you keep an eye on)

If you don't like to do this work by yourself: My colleagues and I are available for rent ;). We'll still ask a lot of uncomfortable questions though. Ok, pun aside, I'll give you a few places to start:

Starting places

Yes, I'll give you a few. You'll have to promise though, that you'll view these as starting points. Everybody's system is different and I don't claim these to be complete (in fact, I'm keeping some options back, giving you the opportunity to shine in the comments;) )

jdbc.default.password: Do you like cleartext passwords to be available on disk, for anybody opening that file? Probably not. Liferay's default configuration uses the manual database configuration with driver, URL, name and password. However, you can also utilize JNDI and just replace the four classic configuration lines with a single entry on jdbc.default.jndi.name. Look it up, now you'll need to configure your application server to make the JNDI connection available to Liferay, and Liferay doesn't have a chance to know the connection password. On Tomcat this AFAIK still means that you have a configuration file with the password in clear text, but that's in tomcat's realm, no longer with Liferay. (Correct me if I'm wrong)

company.security.strangers.*: If you are running an intranet portal, you probably don't want random users to generate new accounts on your portal - by default they can. And if your content administrators just protect content for logged-in users, this can poke some holes.

portal.security.manager.strategy: If you're running 3rd party plugins from marketplace or other developers. If you mandate that plugins have security manager (PACL) enabled - you might want to enforce these settings.

ldap.*: It's easier to move your LDAP configuration around and configure different servers, if it's just a bunch of lines in portal-ext.properties. This might rather be convenience than security, but nailing the login process makes sure that only the right people can log in (and you can test the setup, move it around without typos etc)

*.auth.enabled: Determine the kinds of login that you allow on your system. Do you want to allow OpenID? Enable Facebook?

passwords.encryption.algorithm: On 6.2 Liferay uses a pretty good default. If you're running an older version and keep the hashed passwords in Liferay's database (as opposed to LDAP), you might want to know other options. Should your user database ever get loose, you don't want the hashes to be easy to brute-force.

default.admin.*: I don't like default user accounts, in any system. Even though Liferay comes with its own setup wizard where you can configure the admin user, you shouldn't timeout the session - otherwise you'll find that the default password has been taken from here (ever had a phone ringing while you did administration work? Or worse, a twitter notification or a squirrel in front of your office?)

com.liferay.portal.servlet.filters.*: Various filters that are active by default. If they refer to a product name that you don't know, most likely they can be disabled (e.g. for the SSO options that Liferay supports, you can disable either all or all but the one that you're using)

Take these settings as your starting point. Go further through the file and check what's around these settings. If you have your own favorite configurations that must not miss in this list (hint: it's not complete), consider adding them to the comments on this article. This way everybody gains that knowledge.

User Permissions

New users in Liferay, by default, are members of the roles "User" and "Power User". You can remove the "Power User" association, but should keep "User" as this is a sign that they're authenticated. However, this role comes with quite a lot of permissions. If they match your requirements - I don't know. You should inspect the list of features that they enable. Decide if your users should be able to maintain their own personal sites: This might open you up to malice behaviour if they can add custom administrative portlets to their sites. Liferay's portlets are typically safe and can't be added to personal sites, but you might have more than just the stock portlets.

Not to mention that your helpdesk might be thankful if they don't have to repair your user's personal sites every now and then when they deleted important portlets from their pages.

Do you <script>trust();</script> your content authors?

AntiSamy LogoIf you get what the headline implies: Answer the question. If you do trust them, continue on the next chapter. If you don't get the headline or don't trust your authors: Install AntiSamy (CE or EE) which will "make them trustable" by applying the OWASP rules to their content and eliminating potentially dangerous (scripting) content. You can also implement this functionality yourself by implementing com.liferay.portal.kernel.sanitizer.Sanitizer and configure sanitizer.impl in portal-ext.properties. When you implement this yourself, you can allow certain content that otherwise would be blocked (like embedding content from whitelisted external sites - like youtube - etc)

Portlets

You can disable quite a lot of portlets that Liferay delivers out-of-the-box if you don't need them. In the unlikely event of a loss in cabin pressure (e.g. in case one of them has security-related issues), you don't even have them available. When you choose a product like Liferay, you want it to have as many features as possible. If you want to lock down the installation, you want as few of the unused features being exploitable as possible. Careful: This might annoy your business users that expect to have the full feature set of Liferay available to them.

Portal Instances

I've seen a neat use of portal instances once. While instances are positioned for multi-tenancy, I personally don't really like all of the tenants to be sharing one portal/appserver. However, there's a nice aspect that rarely gets exploited: Only the default instance has access to the server level administration - e.g. only there you can install new portlets, trigger reindexing or garbage collection. When you use your default instance purely for administration and one extra instance for all content, none of your content administrators (not even those with portal-wide administrator roles) will be able to access these features and install server side code through Liferay's UI.

Future chapters

  • Fixing the port 8080 issues (and more HTTP-level issues, like https)
  • more Tomcat lockdown
  • a new episode of Radio Liferay on Security

...coming soon...

Looking forward to see some of you next week at Devcon. Remember to sign up for the community meetup.

Community Meetup at Devcon Darmstadt, 4 November

Company Blogs 30 de octubre de 2014 Por Olaf Kock Staff

Greetings Earthlings that come to Darmstadt for Devcon, the Unconference or LPSF Germany

As last year, we'll have a community meetup. This year we'll be right outside Darmstadt Hauptbahnhof (main station) in a brewery. We'll meet Tuesday, 4 November at 19:30 in Braustüb'l, Goebelstrasse 7.

If you've been there in the previous years, you know the drill: Register for free beer. We have vouchers for you if you are on the list. And you get on the list here. You're welcome to come unregistered - you're just risking to pay for your own beer.

Securing Liferay Chapter 1: Introduction, Basics and Operating System Level

Company Blogs 23 de octubre de 2014 Por Olaf Kock Staff

You probably know the basic installation instructions for Liferay Bundles: „unzip and run startup.sh“ - with this you get to a working Liferay installation in a minute.

While this is great for a quick demo, you might want to do more in case of production setups. This is a part 1 of summary of a workshop held at Liferay's North America Symposium 2014 in Boston. Like in the workshop, it won't give prescriptive information – e.g. you won't be able to hit the „secure“ checkbox – but will have to judge the settings you find for yourself. Also, this guide is not complete: Security is well depending on the general setup, requirements and policies. What works for one is not enough for somebody else. And vice versa. This summarizes things that work for me and that I see working for others. I encourage you to comment on this article if there are aspects that aren't covered but should be taken into account when securing the setup.

The sample setup we'll do (if you want to follow along) uses „Tomcat on Linux with MySql“ as platform. However, I intend to discuss or demonstrate the underlying problems, so that you can still get quite some information out of this series if your platform differs.

Operating System Level

For the purpose of you following along, I'm assuming that the bundle has been deployed to /opt/liferay already. If you want to keep the directory names as they're contained in the zip file, you can achieve this with (pseudocode)

   sudo unzip /path/to/your/liferay-portal-tomcat-6.2-ee-sp8-*.zip /opt/
   sudo ln -s /opt/liferay-portal-tomcat* /opt/liferay
   sudo ln -s /opt/liferay/tomcat-7.0* /opt/liferay/tomcat
   sudo mkdir /opt/liferay/deploy

As you can see, I prefer to have easy pathnames and I've omitted some of the timestamps and version indicators to make the directory structure more readable. If you have multiple versions, the wildcard might do more than you expect.

Typically Production Liferay Systems should listen to port 80 and 443. The easiest way to achieve this is by changing port 8080 to 80 in tomcat's conf/server.xml and then run

   sudo /opt/liferay/tomcat/bin/startup.sh

e.g. run tomcat as root. If you're frightened by this, read on. If you're not frightened by this line, you should: This is the first mistake to avoid. You simply don't want any internet-connected software to be running as root. So the first change is a no-change: Keep tomcat's standard ports (8080) for now – we'll take care of the port issue later – as a first step, we just don't want to run as root.

(Editorial question: Does this statement mislead the quick reader to actually run as root? Should I rephrase this part of the article?)

User Account

To begin, create or identify a specific user account for tomcat. Adjust the actual permissions on the system to minimize access and match your policy. Simplified:

   adduser –system liferay

So, in case I mislead you above: It's really vital that you never run an internet connected process as root. Please don't ever do this. We're using an account that is not allowed to log in to the server, e.g. has no shell (-system). Use what's appropriate on your platform.

Database driver

Before actually starting up tomcat and Liferay, let's make sure the database driver is available. For the purpose of this article, I'm using ubuntu and its bundled mysql, along with the JDBC-Driver (sudo apt-get install libmysql-java). This ensures that I do get operating system level upgrades. Naturally this differs for a different database - especially for commercial ones, you still have to take care of driver updates.

   sudo ln -s /usr/share/java/mysql.jar /opt/liferay/tomcat/lib/ext/

(mnemonic trick to remember the order of parameters for ln: they're following the same semantics as cp – Duh. I felt stupid when sb told me this. Not that I want you to feel this way as well...)

Starting a Daemon & fixing file permissions

Now you might be tempted to already start up our server (sudo -u liferay /opt/liferay/tomcat/bin/startup.sh) but it would still signal several issues when writing temporary- and work files: You probably have unzipped the bundle as a different user, so that “liferay” can't write the temp files. As we want to run tomcat as a daemon anyway, we'll create a script to achieve this and have it do the work of preparing the proper permissions. Here's one that works for me – I don't claim particular shellscript-elegance. (Edit: Read the comments as well as Brett's script) Use your favorite editor to create /etc/init.d/liferay and make it executable:

# Liferay NAS Symposium Boston 2014 auto-start
#
### BEGIN INIT INFO
# Provides:          liferay
# Required-Start:    $apache2 $mysql
# Required-Stop:     $apache2
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# X-Interactive:     true
# Short-Description: Start/stop tomcat server bundled with liferay
### END INIT INFO

export JAVA_HOME=/usr/lib/jvm/default-java

# If Liferay has ever been started (or unzipped) with a different user 
# account than what it's running as, we need to correct permissions.
#
# cd /opt/liferay
# chown -R liferay data deploy
# cd tomcat
# chown -R liferay webapps conf temp logs work
# cd /opt/liferay/tomcat

# run on hardened permissions by default
# chown -R root webapps conf ../deploy

cd /opt/liferay

case $1 in
start)
        # run on softened permissions by default: might need to deploy hooks etc. on startup
        chown -R liferay tomcat/temp tomcat/logs tomcat/work tomcat/webapps tomcat/conf deploy
        sudo -u liferay /opt/liferay/tomcat/bin/startup.sh
        ;;
stop)  
        sudo -u liferay /opt/liferay/tomcat/bin/shutdown.sh
        ;;
soften)
        # can and should be run when the server is running.
        chown -R liferay webapps conf ../deploy
        ;;
harden)
        # can and should be run while the server is running.
        chown -R root tomcat/webapps tomcat/conf deploy
        ;;
restart)
        sudo -u liferay /opt/liferay/tomcat/bin/shutdown.sh
        sleep 5
        sudo -u liferay /opt/liferay/tomcat/bin/startup.sh
        ;;
esac   
exit 0

Note the nonstandard options “soften” and “harden” - we're discussing them later, but maybe it already gives you an idea of what to do with them. (want to contribute to the elegance of this works-for-me script? You might want to add checks to make sure that the directories are actually existing.

Once you have this script (remember to chown root, chmod u+x, chmod go-rwx it)

    sudo service liferay start

With this, we've covered most of the OS side of configuration and the appserver side of Liferay has advanced quite some way. An additional issue that I've not yet taken into account is to run with a Security Manager. Also, we'll leave the port issue (we're still running on port 8080) for later.

Note that an even easier way to cover the OS side is to rely on your operating system's methods to update tomcat - e.g. just install Liferay's WAR distribution and dependencies on top of ubuntu's tomcat (in our example). This would be easier, but it would demonstrate less principles of the installation. But it would come with some nice and fancy daemon script.

Remember: This does not claim to be the absolute truth - please add your own recommendations and different policies/practices. Security never has the absolute truth: If I'd show you how to absolutely nail the implementation you'd complain that nothing works any more. Security is a matter of policy, as much as it is a matter of experience, absence of stupid mistakes and some things more.

Future chapters

  • Securing Liferay's configuration
  • Fixing the port 8080 issues
  • more Tomcat lockdown

...coming soon...

Also, another Radio Liferay episode on security is in the can - scheduled to be published very soon.

Ridiculously Simple Plugins on dev.life

Technical Blogs 26 de agosto de 2014 Por Olaf Kock Staff

This article accompanies the dev.life session "Ridiculously simple plugins" hosted today (26. Aug, 16:00 CEST, 14:00 UTC) by me. The session is broadcasted on youtube and recording will be available (and linked here) after the session.


The purpose of this session is to demonstrate that - given the proper architecture - you can extend Portal Applications within minutes. Well - the story is: Your developer estimates an hour (to do it properly), which means that you might want to round up to the next unit, e.g. 1 day - and this includes documentation, deployment, administration etc.

It's most likely harder to get your system administrator to update the production system yet again than to implement new functionality - given a proper architecture.

Quick start if you want to follow along:

Everything you need is available on www.olafkock.de/liferay/rsp/ and if you don't want to read through everything when we start, pick the instructions with the yellow markers below:

Customers project

During the session we're going to create 3 simple plugins. Two of them are extending a business layer that is generated with XMLPortletFactory. If you'd like, you can download & execute xmlportletfactory yourself with the customer&invoice definition file, but you can also use the shortcut and download this portlet project, unzip it in the portlets directory of your plugins sdk (yes, I'm using Ant, sorry Maveners) and open it in your development environment. For the session I'll use Liferay Developer Studio, but you're free to use whatever you'd like.

What does this project do? It's just what xmlportletfactory generates from the customer.xml script. Actually, I've cheated. It also contains a custom portlet as well that will provide some random data for you. However, it doesn't compile: Consider it to be just the xmlportletfactory output. To make it usable, you'll need to run Liferay's ServiceBuilder.

We'll explore the resulting code during this dev.life session. In short: Add all portlets from the new "Customer" section to a page, create a few customers and invoices and click the icon left of a customer to see the invoices updated.

If you examine the default xmlportletfactory-generated UI, it's not too obvious, which customer is currently selected. You can see it when the icon in a customer's row changes from a square to an arrow. Let's make the current customer more visible by hooking into the already established mechanism of Inter Portlet Communication. The first portlet we create is a CustomerDetailPortlet, showing the name and location of a customer. If we had more business data, we'd probably show more data in the details. (Solution to be linked after the session)

For the next portlet, assume you're using this system, with thousands of customers in the database. Whenever somebody calls, you'll have to search for them again. But when they're calling, they typically call multiple times, delivering more details for their issues. That's why we want to keep track of the latest 5 callers and we'll create a MostRecentlyUsedCustomerPortlet (MRU): This will make it easy to just click on their name, rather than searching for the record again. (Solution to be linked after the session)

What does this teach us? In a portlet environment you can easily compose your application from many different building blocks. If you introduce yet another portlet that interacts with the existing ones, it doesn't need to be big to add value. And it doesn't need to be high-risk to update the site: If your new portlet has a bug - just remove it again. The others will still continue to work, unaffected.

Here's the screenshot of what can be achieved within minutes: (Customer and Invoices Portlets are what xmlportletfactory generated)

Customizing Core Portlets vs. Adding ridiculously Simple Portlets

Time permitting, we'll have one more plugin that demonstrates how to simplify Liferay's UI through a ridiculously simple portlet. If you add WebContent, you'll find that the UI for adding a single article has quite a complex UI. You can translate, tag, expire, categorize your content, provide abstracts etc.

What if your authors are untrained, infrequent users of Liferay? Do you want to train them on the generic UI? They'll probably be annoyed because it's so complex and they don't need all of the features. So why not simplify the UI?

In the forums, this typically comes along as "How do I change the WebContent Editor (or other plugins) to use my defaults?". I'd like to suggest a different approach: Create your own, ridiculously simple plugin. It doesn't mess with Liferay's portlets, is easy to maintain and quick to write. And if the API that you use changes in the next version, you can easily identify the spot to upgrade. In fact, that's exactly what I did - I stole some code from James' 7cogs article and made it work on Liferay 6.2 because the API changed slightly.

So, we're creating a SimplifiedArticlePortlet, which takes an article's title, as well as english and german text through a really simple UI. Point your inexperienced authors to this portlet to add their new articles and you'll be able to take them from there (and you can edit them with the full-featured WebContent editor). Here's a screenshot of the result:

If you follow along (e.g. develop the portlets) during the session, this one is a bit harder to follow - after all it involves an API call with 39 parameters. That's why I've prepared the portlet for you to copy/paste portions as you like: http://www.olafkock.de/liferay/rsp/SimplifiedArticlePortlet.java and http://www.olafkock.de/liferay/rsp/SimplifiedArticlePortlet-view.jsp

What's more?

Given your own applications: Consider to make the best out of the portal environment and compose your big application from many small building blocks. The reward is an easy maintenance of each single component and easy extension of the whole system.

Liferay's API is easy to use (even given occasional 39-parameter methods) and sometimes it's a great option to just hardcode your own logic to a ridiculously simple plugin than to extend and tweak one of Liferay's very generic out-of-the-box portlets. There's a place for generic features, just as there's a place for specialized, narror, behaviour. Choose what makes sense to you and don't fear to write throwaway code: If it's well compartmented (e.g. in a single plugin) there's nothing bad in it.

Update

During the broadcast I didn't finish the MRUCustomerPortlet - here's what needs to be done. The code changes are marked in the solution download that will come up soon - portlet.xml is just updated as required, not marked:

  • Decorate the <li> content on view.jsp with a hyperlink that executes an action
  • Create an action handler in the portlet class, triggering the customerId event
  • Declare that our MRUCustomer portlet does also publish this event in portlet.xml
  • Declare that xmlportletfactory's CustomerPortlet now also processes this event in portlet.xml
  • Implement the eventhandler in CustomerPortlet to highlight the selected row.

And you're done. The full "solution" is now uploaded to customer-portlet-solution.zip.

Note that I do not consider the solution code (or the code presented in the presentation) "good style": When I refer to a "ridiculously simple" plugin, I am stating 1 hour of effort. With the plugins presented here, I took slightly more than 1 hour for 3 plugins. Naturally this means I'll need a few shortcuts that shouldn't actually go into production code. But you get the point.

Mostrando el intervalo 1 - 20 de 97 resultados.
Elementos por página 20
de 5