OpenLogic Blogs » Dave

Synching Apache and JBoss Timezones

Dave — Fri, 26 Jun 2009 20:20:00 +0000

We've had a couple customers recently ask us how to synch the timezones for Apache web server and JBoss Application Server.

The question goes something like this:

I have servers living in Arizona. Our Linux team has set the native time to AZ. I need to set the apache and JBoss to CT for testing. How can this be done?

This question has two answers:

1. Apache uses the operating systems TZ variable to set the timestamp in the log files. Unless you are using any cgi scripts like php or perl on the server you can't change the Apaches TZ. If you have php you would change the TZ in php.ini and perl in the perl.conf but if Apache is just handling static files or it is a mod_jk/proxy server you can't change the apaches TZ unless you change the servers TZ.

2. JBoss TZ is different. In your JBoss startup script make sure you xport the TZ variable like so:

export TZ='CST'

If you want to do this for testing purposes you can just execute the export before you start JBoss.

Top 5 Reasons to Join the OXC

Dave — Thu, 11 Sep 2008 23:01:46 +0000

The OpenLogic Expert Community (OXC) is a growing community of open source committers, contributors and experts who help us in supporting over 400 open source projects. The community is open to people who have the passion, time, and knowledge to help solve technical issues on any of the open source products in our library. Are you interested in joining? Would you like to know more? Here are just 5 of the top reasons you may want to consider joining the OXC today:

Compensation. Get paid to do what you love. Do you like solving configuration issues for Apache? We normally pay $100 for each ticket you resolve. If it's more complex we will pay more.
Promote Your Project. Whether your project has one committer (you!) or a hundred, we actively sell support to large enterprises on everything in our library. By joining our community you help us promote the use of your project to enterprise users.
Do What You Love. You probably are involved in open source because you are passionate and excited about your project. The OXC offers you yet another opportunity to use your expertise to help others better use your projects.
Develop New Expertise. You don't have to be a committer or contributor on a project to help us resolve a customer issue. You may be a PHPAdmin expert who can help us resolve a generic PHP question. If you have the skills you can choose to take on an issue on a new project to help you develop new skills.
Promote Open Source. Help us get the word out. Open source works! By joining our community you help us create the positive image open source deserves.

If you are interested in learning more, please visit our community page. Or join today by filling out the OXC application: http://www.openlogic.com/community/join.php.

Don’t Judge an Open Source Project by its Cover

Dave — Thu, 31 Jul 2008 22:50:01 +0000

At OpenLogic we review open source software prior to adding it to our certified library. Projects get added to our queue in a number of ways, but more often than not, customers contact us and let us know they are using a project and ask us if we will review, certify and add the project to our library. The first step in our certification process is to verify that the project is indeed open source. For example, we automatically disqualify projects that are "free" or "demo" products that aren't provided with source code. But more importantly, we review the terms under which the package is licensed. This is probably the best way to determine if the project is really open source or not. Many times it is easy to tell if it is an open source license, for example if the license is well known (like GPL or the Apache License) or if it is based on a well known license (like BSD) with minor, inconsequential changes. But often, the licensing is not so cut and dry.

A few weeks ago a customer asked us to review a package. After reviewing the website I was unable to find any information on licensing. It is a common practice for community web sites to either include a statement on or link to licensing information. So, I downloaded the project and unpacked the distribution. Another common practice is to place the project license in the root directory. Again, I found nothing. So I contacted the project owner. He let me know that he had not given it any thought and that he had not chosen a license yet. And, yet the project was over 2 years old!!

I gave him some links to resources on licensing open source projects: the Open Source Initiative and the Free Software Foundation. I also mentioned that Wikipedia has tons of great information on open source licensing. I also offered some advice on the importance of understanding his goals in respect to his project. Did he want to be less or more controlling over what ultimately happens with his projects source?

His project is actually a subproject of a very well known open source project. So he sought the advice of his contact at the parent project and now has plans to officially license his project using a standard open source license very soon.

This story illustrates just one of the many ways that determining whether a project is really open source, and more importantly, how a project is licensed can be very difficult and time consuming.

This is not the first time we've had companies ask us to add "open source" packages to our library that are not a licensed open source project. I think there are a few lessons in this story. But ultimately, if your responsibility is to understand how a project is licensed and that your organization is in compliance with the terms and conditions of that license, you can never assume a project is open source until you have the license in hand. Even if the project is a subproject of a well known open source licensed project.