Monday, August 31, 2015

WebSphere MQ Explorer requires root access

WebSphere MQ Explorer is my favourite tool because command line isn't easy to use. This component requires separate installation apart from the MQv8 installation. And it requires root user which has mqm group granted in order to create a queue. Otherwise a prompt showing following error stopping me to proceed further.
****************************************
* Command: /opt/mqm/bin/crtmqm  Q1
****************************************
Access not permitted. You are not authorized to perform this operation. (AMQ4036)
As of this writing, this tool was installed in Ubuntu 14.04, and it was launched in Unity Launcher. Open this file: /usr/share/applications/IBM_WebSphere_MQ_Explorer-Installation1.desktop (this file requires root access as well), and modify the line:
...
Exec=/opt/mqm/bin/MQExplorer
...
with this:
...
Exec=gksudo -k -u root /opt/mqm/bin/MQExplorer
...

Saturday, August 29, 2015

Permission denied on crtmqm

This is so not good. I'm not able to create a queue after the WebSphere MQ installation. Following error was seen when I issue the command:
$ crtmqm Q1
bash: /usr/bin/crtmqm: Permission denied
$ sudo crtmqm Q1
AMQ7077: You are not authorized to perform the requested operation.
It has been so struggling with me at first, but later I have conquered the fear. As mention from this reference guide, I got a strong sense that I have not assigned my user ID to mqm group. Below is the text extract from the reference guide:
In WebSphere MQ, user id "mqm" and any ID which is a part of "mqm" group are the WebSphere MQ administrative users. WebSphere MQ queue manager resources are protected by authenticating against this user. Since the queue manager processes use and modify these queue manager resources, the queue manager processes will require "mqm" authority to access the resources. Hence, WebSphere MQ queue manager support processes are designed to run with the effective user-id of "mqm".
Since crtmqm is referring to /usr/bin/crtmqm, and it requires root access to it, thus it is wise to grand mqm group to the root user account instead of my user account.

Wednesday, August 26, 2015

MQv8 installation hit user limit error

Sigh~ There is another error while the MQv8 installation is undergoing. This time, the error was logged into a file, part of content causing the installation fails were shown here:
...

Current User Limits (root)
  nofile       (-Hn)  4096 files                         IBM>=10240        FAIL
  nofile       (-Sn)  1024 files                         IBM>=10240        FAIL
This has reminded me somewhere in the documentation did mention about the limit thing. Thus in my case, just append following configuration into /etc/security/limits.conf. This file may require root access in order to edit it.
...

mqm             hard    nofile          10240
mqm             soft    nofile          10240
# End of file
This should be the last error I face during the installation. Sometimes I do wonder where will be the installation path is? Do this trick, issue a command dspmqver, then it directs me to his new home. This is something what I will see:
Name:        WebSphere MQ
Version:     8.0.0.2
Level:       p800-002-150303.DE
BuildType:   IKAP - (Production)
Platform:    WebSphere MQ for Linux (x86-64 platform)
Mode:        64-bit
O/S:         Linux 3.13.0-62-generic
InstName:    Installation1
InstDesc:    
Primary:     No
InstPath:    /opt/mqm
DataPath:    /var/mqm
MaxCmdLevel: 801
LicenseType: Developer

Tuesday, August 25, 2015

Cannot open Packages database during MQ installation

Continuing from the journey of previous installation on WebSphere MQ. This time, IBM has offered WebSphere MQ free of charge, the link of the site is here. As of this writing, I'm getting the MQv8 for Linux. No more waiting! This is a damn real great news for a poor guy like ME!

While I was about to install MQ after the step ./crtmqpkg suffix, something "abnormal" was blocking my way.
kokhoe@KOKHOE:/var/tmp/mq_rpms/LKH/x86_64$ sudo rpm -ivh --force-debian MQSeriesRuntime_LKH-8.0.0-2.x86_64.rpm 
error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch
error: cannot open Packages index using db5 -  (-30969)
error: cannot open Packages database in /home/kokhoe/.rpmdb
error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch
error: cannot open Packages database in /home/kokhoe/.rpmdb
I think this error doesn't belong to MQ specific because it happened on another package installer too. The clue I found was there is a hidden folder, .rpmdb is having some conflict since previous installation. By just removing that folder will make the rpm program smiling.

Friday, August 21, 2015

log4cpp::Category::xxx() do accept c_str()

Just got to know that in order to log a value of boost::filesystem::path with log4cpp, it is just as simple as follows:
   Category *pRoot = NULL;
   PropertyConfigurator::configure("log4c.properties");
   pRoot = &(Category::getRoot());

   path targetPath("./the_path");
   pRoot->info("%s", targetPath.c_str());
Assuming I have the following content in log4c.properties:
   log4cpp.rootCategory=DEBUG, rootAppender

   log4cpp.appender.rootAppender=ConsoleAppender
   log4cpp.appender.rootAppender.layout=PatternLayout
   log4cpp.appender.rootAppender.layout.ConversionPattern=%d [%p] %m%n

   ...
But before I got to know this, I heard there are people mention that the conversion from c_str() to const char* would not be straightforward. And it would require wcstombs() to do the conversion, thus I come out this:
   ...

   char pathName[50];
   memset(pathName, '\0', sizeof(pathName));
   wcstombs(pathName, targetPath.wstring().c_str(), sizeof(targetPath.native().length()));
   ...
Is this what they mean? Or I misunderstood something? No worry, log4cpp::Category::xxx() do accept c_str(). 

Monday, August 17, 2015

Setting up log4cpp with CMake

Remember last time when I was writing software application on C programming, this is what I did in diagnosing defects in the application.
#ifdef __DEBUG__
    // logging code here
#endif
This piece is everywhere, trapping malicious bugs. The usage of this piece is like this; If I want the log to show up, I turn on the __DEBUG__ switch like this: #define __DEBUG__, otherwise I'll remove the switch to turn it off.

Looking back my foolish happened in the pass, is a shame. Inspire from JAVA's log4j, I wish I could have something similar thing on C. Yup, there is one called log4cpp and it exists in the world for so long. It has very much similarity to log4j, just that some cautious to take attention during the initial setup.

As I'm using CMake in my project, the installation guide from the site don't have much detail on that. After some try and error, finally I need to have following piece in CMakeLists.txt:
...

include_directories(/usr/local/include/log4cpp)
link_directories(/usr/local/lib/)
find_package(Threads REQUIRED)

target_link_libraries(myprogram liblog4cpp.so ${Boost_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT})

...
The first line is to tell where the log4cpp's header files location, the second line tells where can I load the log4cpp's library. Never though of log4cpp has a dependency on threading library, it requires -pthread option in the build, otherwise following error would be seen:
...

/usr/local/lib/liblog4cpp.so: undefined reference to `pthread_key_create'
/usr/local/lib/liblog4cpp.so: undefined reference to `pthread_getspecific'
/usr/local/lib/liblog4cpp.so: undefined reference to `pthread_key_delete'
/usr/local/lib/liblog4cpp.so: undefined reference to `pthread_setspecific'
Thus, ${CMAKE_THREAD_LIBS_INIT} will do the trick. The last line will wrap up the build and log4cpp is ready to serve.

Goodbye to the ugly code.

Friday, August 14, 2015

When I move to Mars...

This is so not good, JBoss server was not functioning after I have upgraded my workspace to Eclipse Mars. I'm not even able to create new JBoss server as the server adapter was also gone missing.

There 2 requirements need to fulfill in order to get JBoss work under Eclipse Mars:

Requirement 1
Eclipse Mars must have JBoss Tools 4.3 installed. As of this writing, I'm using 4.3.0.Beta2 (the only version works on Eclipse Mars). It can be downloaded from Eclipse Marketplace or JBoss Tool's website.

Requirement 2
JBoss Tools 4.3 need to feed by JDK 8 as mention in this blog. I don't really want to disturb my global environment variable, JAVA_HOME, as she is serving for peoples too. Thus, what I'll do is to configure it in eclipse.ini.
-vm
/home/user/tool/jdk1.8.0_51/bin/java
-vmargs
-Dosgi.requiredJavaVersion=1.7
-XX:MaxPermSize=256m
-Xms256m
-Xmx1024m
Do take note that -vm must before -vamrgs, otherwise -vm will become argument of -vamrg.