Spirited living
Sunday, November 16, 2014
Set fire to the rain ...
Sunday, October 26, 2014
Linux yum update: Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again
Looks like the connection to repository has not been successfully established.
Show details about the error by:
$ URLGRABBER_DEBUG=1 yum check-update ........
Temporary working around ... You could try with 1 of 2 options below:
1. Change the Extra Packages for Enterprise Linux (EPEL) configuration
locate epel.repo, example /etc/yum.repos.d/epel.repo
$vi /etc/yum.repos.d/epel.repo
Search for, and mask the mirrorlist: #mirrorlist
Search for, and unmask the baseurl: baseurl=....
2. Temporarily change the epel related files' names in /etc/yum.repos.d/
$ mv epel.repo epel.repo_bk
$ mv epel-testing.repo epel-testing.repo_bk
Then, go ahead to update.
$ yum clean all
$ yum update
Show details about the error by:
$ URLGRABBER_DEBUG=1 yum check-update ........
Temporary working around ... You could try with 1 of 2 options below:
1. Change the Extra Packages for Enterprise Linux (EPEL) configuration
locate epel.repo, example /etc/yum.repos.d/epel.repo
$vi /etc/yum.repos.d/epel.repo
Search for, and mask the mirrorlist: #mirrorlist
Search for, and unmask the baseurl: baseurl=....
2. Temporarily change the epel related files' names in /etc/yum.repos.d/
$ mv epel.repo epel.repo_bk
$ mv epel-testing.repo epel-testing.repo_bk
Then, go ahead to update.
$ yum clean all
$ yum update
Wednesday, October 15, 2014
Friday, August 22, 2014
Configuring SSL between Worklight adapters and back-end servers which are protected by self-signed certificates
SSL is usually used to secure the communication between endpoints and when it comes to Worklight environment, there might be some hick-ups you need to workout. This post provides some basic steps with the hope to help you out.
Here is what you might have (Oops, sorry):
Http request failed: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
FWLSE0101E: Caused by: [project bond]javax.net.ssl.SSLPeerUnverifiedException: peer not authenticatedjava.lang.RuntimeException: Http request failed: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.worklight.adapters.http.HTTPConnectionManager.execute(HTTPConnectionManager.java:241)
at com.worklight.adapters.http.HttpClientContext.doExecute(HttpClientContext.java:185)
at com.worklight.adapters.http.HttpClientContext.execute(HttpClientContext.java:169)
at com.worklight.adapters.http.HTTP.execRequest(HTTP.java:146)
at com.worklight.adapters.http.HTTP.invoke(HTTP.java:135)
at com.worklight.integration.model.ProcedureInvoker.invokeProcedure(ProcedureInvoker.java:57)
- You have keytool installed together with Java in your machine
- This tutorial aims to help developers to setup their local development environment, specifically on Mac OS X, with WAS Liberty profile.
Retrieve the public certificate from the server to which your adapters are connecting.
There are several ways to do this but since you have openssl installed, simply use it
- Try to connect to the_remote_server:port using openssl on you console:
$openssl s_client -connect the_remote_server:port
- The command will result some information displayed on your console. Capture the certificate information:
- Create a text file (name it server_cert.cer), and copy the cert information displayed in the previous step, into the file, including -----BEGIN CERTIFICATE---- and -----END CERTIFICATE-----
- You now have the cert file at: path_to_your_cert_file/server_cert.cer
Add the cert into your Worklight Server’s JRE’s keystore.
- First, you need to locate the place where the keystore file placed. In your Worklight studio, to go Preferences settings:
Then go to Server >> Runtime Environments >> Select the server >> Edit
- In this case, the_path_to_keystore will be:
/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home/jre/lib/security/cacerts
- Use keytool to import the server_cert.cer into the keystore:
$keytool -import -trustcacerts -alias "an_alias" -keystore the_path_to_keystore -file path_to_your_cert_file/server_cert.cer
- Enter password of the keystore, default one is “changeit”, type “yes” if asked.
- Check if the cert is actually added in:
$keytool -list –keystore the_path_to_keystore
Add non self-signed cert to Worklight Server’s keystore
With SSL cert that is not self-signed, you still need to add it to the keystore which is being used by your Worklight Server at least. Assuming you already retrieved the cert with the method described in section 1. Below are some more steps to go:
Go to the Worklight Server’s configuration to locate where the keystore is:
- You get the location of the keystore in the Location text field above (worklight_keystore_path)
- Use keytool to import the cert into the keystore:
$keytool -import -alias an_alias -file path_to_your_cert_file/ server_cert.cer -keystore worklight_keystore_path
- Restart your Worklight Server
Here is what you might have (Oops, sorry):
Http request failed: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
FWLSE0101E: Caused by: [project bond]javax.net.ssl.SSLPeerUnverifiedException: peer not authenticatedjava.lang.RuntimeException: Http request failed: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.worklight.adapters.http.HTTPConnectionManager.execute(HTTPConnectionManager.java:241)
at com.worklight.adapters.http.HttpClientContext.doExecute(HttpClientContext.java:185)
at com.worklight.adapters.http.HttpClientContext.execute(HttpClientContext.java:169)
at com.worklight.adapters.http.HTTP.execRequest(HTTP.java:146)
at com.worklight.adapters.http.HTTP.invoke(HTTP.java:135)
at com.worklight.integration.model.ProcedureInvoker.invokeProcedure(ProcedureInvoker.java:57)
Assumption
- You have installed openssl tool on your machine- You have keytool installed together with Java in your machine
- This tutorial aims to help developers to setup their local development environment, specifically on Mac OS X, with WAS Liberty profile.
Way to go
Retrieve the public certificate from the server to which your adapters are connecting.
There are several ways to do this but since you have openssl installed, simply use it
- Try to connect to the_remote_server:port using openssl on you console:
$openssl s_client -connect the_remote_server:port
- The command will result some information displayed on your console. Capture the certificate information:
- Create a text file (name it server_cert.cer), and copy the cert information displayed in the previous step, into the file, including -----BEGIN CERTIFICATE---- and -----END CERTIFICATE-----
- You now have the cert file at: path_to_your_cert_file/server_cert.cer
Add the cert into your Worklight Server’s JRE’s keystore.
- First, you need to locate the place where the keystore file placed. In your Worklight studio, to go Preferences settings:
Then go to Server >> Runtime Environments >> Select the server >> Edit
- In this case, the_path_to_keystore will be:
/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home/jre/lib/security/cacerts
- Use keytool to import the server_cert.cer into the keystore:
$keytool -import -trustcacerts -alias "an_alias" -keystore the_path_to_keystore -file path_to_your_cert_file/server_cert.cer
- Enter password of the keystore, default one is “changeit”, type “yes” if asked.
- Check if the cert is actually added in:
$keytool -list –keystore the_path_to_keystore
Add non self-signed cert to Worklight Server’s keystore
With SSL cert that is not self-signed, you still need to add it to the keystore which is being used by your Worklight Server at least. Assuming you already retrieved the cert with the method described in section 1. Below are some more steps to go:
Go to the Worklight Server’s configuration to locate where the keystore is:
- You get the location of the keystore in the Location text field above (worklight_keystore_path)
- Use keytool to import the cert into the keystore:
$keytool -import -alias an_alias -file path_to_your_cert_file/ server_cert.cer -keystore worklight_keystore_path
- Restart your Worklight Server
Friday, August 15, 2014
Three key focus areas for a bank to get started on mobile journey
Mobile has been significantly changing the way banks service their
customers. It’s forcing banks to innovate, transform and try new ways of
reaching, engaging and communicating with customers. At the same time
it is moving the banking industry away from specific places, products
and processes to capabilities that are available when and where
customers need them. If your bank was to get started on a mobile journey
today, below are three key focus areas that you should consider.
Mobile banking
Mobile banking enablement recently became an important deciding factor for a customer choosing a bank—just as important as fees, branch location or services.
This is the first transformation action you should take for your bank in order to monetize opportunities brought in by mobile. It starts with offering basic banking functions such as:
Mobile payment
Garner predicts an explosion in the mobile payments market worldwide that is expected to have 448 million users and $617 billion in transaction value by 2016. This trend could potentially introduce a major source of revenue that banks cannot ignore.
In developed markets, where mobile access to financial services is more prevalent and comfortable, mobile payments represent a chance to create feature-rich products that enhance consumers’ banking experience and consequently create better consumer sentiment toward the use of mobile in financial transactions.
Even in developing countries where a significant number of people do not have any bank accounts, mobile still can fill the gap, bring the banking to a new customer base, the un-backed people. This represents an opportunity to create profitable services for the unbanked populations through partnerships between banks and payment or telecommunication companies.
As predicted by the Aite Group, the top mobile payment markets in 2015 by volume will be bill payments, bankcard acceptance, mobile commerce, NFC payments and person-to-person transfers. More information about mobile payment patterns currently available in the market worldwide can be found here.
In all cases, in order to catch the explosion of mobile payments, banks will need to act quickly with a complete mobile strategy that not only covers their infrastructure adaptation as the inevitable transaction volume increases and puts growing pressure on their traditional systems, but also innovates their processes to serve this new, always-on revenue stream.
Mobile marketing
Timing is critical to creating delightful engagement experiences for banking customers. It’s about reaching them in the right place, at the right time, with the right kind of service or message. With the natural, always-on characteristic, and its many other features, mobile could provide a new opportunity to engage, cross-sell, up-sell and promote other banking products or services, like analytics-powered, event-driven and location-based services—just to name a few. As an example, an air ticket purchase might present a chance to cross-sell travel insurance; or a person who steps into a mall could trigger sending him information about a retail promotion program of the bank to buy things in the mall.
People nowadays are embracing mobile in their day-to-day lives and are more likely to forget their wallet at home than their mobile phone. Every mobile device a consumer has can potentially be a commerce device. Your bank needs to transform to catch the trends, be well prepared and focus on key areas that could effectively drive your benefits.
*This post was originally published on IBM Mobile Business Insights
Mobile banking
Mobile banking enablement recently became an important deciding factor for a customer choosing a bank—just as important as fees, branch location or services.
This is the first transformation action you should take for your bank in order to monetize opportunities brought in by mobile. It starts with offering basic banking functions such as:
- account balance
- funds transfer
- bill payments
- share trade
- check order
- transaction notification alerts on mobile devices
Mobile payment
Garner predicts an explosion in the mobile payments market worldwide that is expected to have 448 million users and $617 billion in transaction value by 2016. This trend could potentially introduce a major source of revenue that banks cannot ignore.
In developed markets, where mobile access to financial services is more prevalent and comfortable, mobile payments represent a chance to create feature-rich products that enhance consumers’ banking experience and consequently create better consumer sentiment toward the use of mobile in financial transactions.
Even in developing countries where a significant number of people do not have any bank accounts, mobile still can fill the gap, bring the banking to a new customer base, the un-backed people. This represents an opportunity to create profitable services for the unbanked populations through partnerships between banks and payment or telecommunication companies.
As predicted by the Aite Group, the top mobile payment markets in 2015 by volume will be bill payments, bankcard acceptance, mobile commerce, NFC payments and person-to-person transfers. More information about mobile payment patterns currently available in the market worldwide can be found here.
In all cases, in order to catch the explosion of mobile payments, banks will need to act quickly with a complete mobile strategy that not only covers their infrastructure adaptation as the inevitable transaction volume increases and puts growing pressure on their traditional systems, but also innovates their processes to serve this new, always-on revenue stream.
Mobile marketing
Timing is critical to creating delightful engagement experiences for banking customers. It’s about reaching them in the right place, at the right time, with the right kind of service or message. With the natural, always-on characteristic, and its many other features, mobile could provide a new opportunity to engage, cross-sell, up-sell and promote other banking products or services, like analytics-powered, event-driven and location-based services—just to name a few. As an example, an air ticket purchase might present a chance to cross-sell travel insurance; or a person who steps into a mall could trigger sending him information about a retail promotion program of the bank to buy things in the mall.
People nowadays are embracing mobile in their day-to-day lives and are more likely to forget their wallet at home than their mobile phone. Every mobile device a consumer has can potentially be a commerce device. Your bank needs to transform to catch the trends, be well prepared and focus on key areas that could effectively drive your benefits.
*This post was originally published on IBM Mobile Business Insights
Mobile enterprise: Overcoming the security challenges
Even though the use of mobile in business is becoming more prevalent,
there are still big concerns about it from a security standpoint.
Security concerns significantly influence how confident people are about
applying mobile technology within their organizations. According to the
survey results talked about in a recent press release (download available here)
from the US Federal Reserve System, 25 percent of mobile phone users
believe their personal information is “somewhat unsafe” when using
mobile banking and 18 percent believe that it is “very unsafe.” The
natural portability of mobile technology and other characteristics
specific to the mobile environment demand that your organization’s
approach to address these security issues is sufficient enough to gain
the users’ confidence and to actually win competitive advantages by
using the technology. Below are three key focus areas you should
consider when implementing security for your mobile enterprise.
1. How to secure the device and corporate data
You need a complete solution that will protect corporate-owned devices as well as the bring-your-own-device (BYOD) types of devices that people use with the expectation of accessing enterprise resources. Management of these devices should include enrolling and provisioning the device when it comes into your enterprise environment. Given how easy it is for a device to be misplaced or stolen, data loss prevention is of the utmost importance. Hence, being able to remotely lock, locate and even wipe corporate applications, documents and settings without touching personal information is a fundamental requirement for the solution you choose. You need to ensure that you can enforce your enterprise policy on these devices—passcode, jail-breaking and rooting detection, encryption and so on—and that you have the ability to fingerprint each device. This means that not only should you be able to look at the media access control (MAC) address or name of the device, but you should be able to deeply inspect it to determine if you can trust the device and its user.
Also, the natural portability of the mobile environment is
challenging your organization to have sufficient control over the data
that is being stored on or shared across devices. Sensitive corporate
information can be leaked from these devices during sharing activities.
The technology you choose should allow users the freedom to share, cut
and paste information between their mobile enterprise applications, but
should also be able to keep this information separate from any of the
users’ personal applications.
2. How to secure the application
One well-known approach for securing applications is containerization. Essentially, this means putting a security perimeter into your application itself to enforce enterprise security policy and to prevent data from leaking out of the application. In order to do this, it’s critical to consider both a software development kit (SDK) and an app-wrapping approach to support both the apps you develop and the apps you buy.
The first thing you need is a comprehensive mobile application
development lifecycle approach as well as a comprehensive integrated
development environment (IDE) where you can include these security
considerations by design. You need to detect the security
vulnerabilities in every corner of your application while it is being
developed, not after. Besides applying best practices and writing
secured source code, you can use static scanning tools (for example, IBM Security AppScan) to automate the security assurance. A comprehensive IDE like IBM Worklight Studio
can help your development team to implement a security strategy on all
of your mobile applications for a wide range of supported mobile
platforms. An IDE can also extensively enforce this strategy vertically
on each platform by making use of platform-specific, security-related
features.
The next thing you should do is put the instrumentation into the apps
that is necessary to wrap the apps into a container and then harden the
app. Lack of binary protection is the newest item in the top 10 mobile security risks introduced by the Open Web Application Security Project (OWASP)
in 2014. Given that, it’s important that you make it difficult for an
attacker to go in and identify a weakness in your application, inject
malware, recompile and redistribute the app.
3. How to secure the transaction
This focus area is about securing the transactional workloads that occur on the mobile devices between clients, business partners, contractors and so on within your organization. You may want to make sure that you have both access control as well as transaction integrity for all interactions (even for ones that involve users that are not part of the security framework being used by your employees).
In order to secure the transaction, your organization should use a
robust mobile access management system and have a strong
fraud-prevention and detection approach at all points of impact. Your
fraud-prevention approach should include cross-channel fraud detection,
IP velocity, mobile malware detection and real-time detective services.
These are some of the key security focuses in mobile enterprise, but
there are probably others. What do you see as possible security
challenges in mobile enterprise? Leave your comments here or follow me
on Twitter @duyhat to discuss further on how to effectively overcome security challenges in your mobile enterprise.
*This post was originally published on IBM Mobile Business Insights
Tuesday, May 27, 2014
What could go wrong with your enterprise mobile application?
Developing and releasing mobile applications can be a difficult business, especially in the enterprise context, with a lot of expectations and constraints. In this post we’ll talk about some common challenges you may have with enterprise mobile applications.
You cannot smoothly deploy and distribute your app
When an app is ready for release, you might be stuck at how to move forward with deploying it because you did not take into account some critical dependencies on a platform-specific deployment process. For example, if you want to host your app in a public app store, you need to mindfully consider the approvals process of the app store owner, the audits your app needs and the app’s capabilities once it’s deployed there due to the deployment constraints. If the app is going to be deployed in an enterprise app store, in many cases you need to know how to get enrolled into the proper developer programs as well as how to provision and profile your app accordingly. You need to be aware of the dependencies of the app on the mobile device management (MDM) platform that your organization is using.
Also, you need to consider the download size of your app, what part of the app should be bundled into the installation package, what part should be distributed later as the user uses the app and so forth. You might also be struggling with how to inform your users about a new version of your app and how to have it conveniently updated on their devices. All of these can obviously create problems that may impact your deployment plan.
Your app crashes, freezes or behaves weirdly
A poor testing plan that did not sufficiently cover all the aspects of your app when it goes live usually causes the quality issues. With the wide adoption of bring your own device (BYOD) in the enterprise, testing becomes a huge, challenging task in mobile app development due to the diversity of mobile devices and operating systems in the market.
Even though simulators are your friends they can’t substitute for real devices. Manual testing, or interactive testing, which involves real human beings trying the app on real devices, is still a crucial testing method even though it is expensive and requires a lot of effort. You should incrementally involve users from different departments in the testing cycle to make sure your app is frequently tested before rolling it out at the corporate level. Manual interactive testing works best in many scenarios, especially nonfunctional testing like performance and user experience evaluation. You may also want to consider testing in the wild with poor connection or battery draining; device-specific testing on resolution and orientation; or even testing with different carriers, which could cause strange behavior in your app.
Your app is too complex
One of the common pitfalls is putting too many features that involve resource-consuming functions into a single mobile app, which complicates navigation within the app, challenges the user or drains the battery quickly. Due to the natural small screen of the mobile device and its limited computing resources I recommend that you make your mobile app as simple and lightweight as possible in terms of functionalities and resource consumption so that the battery won’t be drained even before the user gets used to the app. User satisfaction is usually higher when an app has fewer but better-defined functions, rather than a broad range of complicated features. The user’s expectation usually includes the ability to conveniently complete complex tasks in the simplest way possible.
Your app’s usability is poor
Enterprise apps usually do not get enough focus on user experience design and are not typically as polished as consumer apps. Meanwhile, employees still expect to have an equivalent level of usability. Even though enterprise mobile apps often have a different mission and have more going on than consumer apps, they share the same challenges when used on mobile devices.
The usability expectation is that apps be intuitive and easy to use. It’s reasonable if the users ignore your app because of its lack of user-friendly design, poor navigation experience and so forth. The mobile application also should not be data intensive and should help your employees to easily browse its functionalities and get results instantly.
You lack support and maintenance or a way to track results
Perhaps your users do not know how and where to get help when they have trouble using the app. Or the users have the app, but no one is following up to see if it’s being used, how often it’s being used and if people are happy about the app.
It’s crucial to plan for app usage statistics and a feedback recorder up front and to spend effort on analyzing and managing them to continuously address users’ concerns and feedback. App analytics is critical to keep your mobile app essential to its users and drive your users’ satisfaction to meet the business needs.
The last stage of your mobile app is not deployment. It’s ongoing support, a learning effort to know what works and doesn’t work for your users, in context, to better ensure the business value of your app.
To avoid most of these headaches, you need a comprehensive mobile application lifecycle management approach that is sufficient for your needs and can offer agility to your enterprise. And that’s where IBM MobileFirst can help with its mobile application development lifecycle offering.
*This post was originally published on IBM Mobile Business Insights
Wednesday, February 19, 2014
Configuring SSL for IBM HTTP Server (IHS) and IBM Websphere Application Server
Many times when working with Java 2 enterprise edition applications, you need to enable the SSL to secure the communication between endpoints of your app. This post aims to provide an instruction on how to create a SSL certificate using ikeyman tool and install it on an IHS, WAS pair which are running on Linux alike environment
A typical simple web architecture using IBM products would have an IHS running upfront as a web server to handle all requests from client(s) and then navigate them to a WebSphere Application Server (WAS). This chart may quickly describe the architecture:
So the connections need to be encrypted are as following:
1.
Connection between the web browser and the IHS
2.
The connect between the IHS and the WAS
Creating new SSL certificate using iKeyman tool
iKeyman is a GUI based tool that helps you to manage digital
certificates. It can be used to create key database, test a digital
certificate, add certificate authority roots to the database, copy certificate
between databases, request and receive certificates from a certificate authority,
and so forth.
iKeyman can be found in IBM Http Server, WAS or IBM Jre
installation packages.
There are two types of certificate you can use: self-signed
and signed by a certificate authority. Let’s take the second one in our
example.
First step for this is creating a key database:
-
Start iKeyman tool: $sh /IHS root
dir/bin/ikeyman.sh
-
Click on the Key Database File menu, and select
New … , or click on the “New…” icon on the toolbar
-
Select CMS as Key database type and name the
file, locate the location of the database file respectively
-
Set the password for the database and stash the
password to the file if necessary.
-
From the Create menu, select New certificate
request … menu item, or click
on the Create a new certificate request button on the tool bar
-
Carefully fill in the necessary information for
the CR, example:
-
Save the certificate request to a place that can
be used later to submit to CA for issuing the certificates
-
After receiving the signed certificate files from the certificate authority,
open the key database using the iKeyman tool and in
the Key database content, select Personal Certificates and click Receive …
button
-
Browse the cert file you just downloaded in the
step above, click OK and you have the certificate ready to use.
-
Now copy the .kdb and .sth files over to your
IHS server location and be ready for the next steps.
Configuring IHS for the SSL cert
-
Open the httpd.conf file of your IHS and modify
it to use the .kdb and sth files created in the steps above
Here is an example:
LoadModule
ibm_ssl_module
modules/mod_ibm_ssl.so
<IfModule mod_ibm_ssl.c>
Listen 443
<VirtualHost duyshat.com.vn:443>
SSLEnable
SSLTrace
SSLClientAuth None
SSLProxyEngine on
SSLServerCert duyshat.com.vn
Keyfile
"/path/to/keydatabasefile/duyshat.com.vn.kdb"
SSLStashFile "/path/to/passwordfile/duyshat.com.vn.sth"
ErrorLog logs/https-error_log
</VirtualHost>
</IfModule>
-
Restart the IHS server
-
You’re done.
Subscribe to:
Posts (Atom)