Well, there went 2 days of my life I won’t get back. 🙂
About 2 weeks ago, when I booted up my SLES 64-bit Linux server, it complained about issues with the hard drive. So, I ran “fsck” to fix the file system issues. There was only a couple of problems then everything was fine. I had booted the server a couple of more times then it happened again (Note: I don’t leave the server running because I don’t use it every day). Again, I ran fsck and then the OS was happy. I have a backup of everything on it, but I figured I would backup important files again. Last Wednesday, it happened again that the OS complained. I fixed it but on Thursday, everything went sideways. While using it, the OS started complaining that it could not find executables like “ls” command. I tried to “sudo” to root but command not found. I tried to shut it down from the console but nothing. I did a hard reset of the server and let cool off. I figured I was SOL but you never know. A hour later, I powered it on but the OS just hung.
So, I pulled the box out of the rack, opened it up to see what hard drive it had. Now, this server is probably 10-11 years old (I know, nothing last forever). The hard drive was a Seagate Barracuda 500GB SATA2. I copied the motherboard model (ASUS P5E-VM DO) then downloaded the manual to see what it supported which was SATA2 (and SATA1). I got curious if I could use a SSD drive and after a few searches it appeared so. I checked my local computer store to see what they had but all they had were SATA3. Again, a quick internet search says that SATA3 is backward compatible.
I purchased a Samsung 860 EVO. I installed it, screwed the case closed and put it back in the rack. Nope, didn’t check it because how dumb can you be to screw 4 screws and plug in 2 cables. Booted it up and went into the BIOS and no hard drive. Did a refresh, nothing, rebooted it, still nothing. Started to swear. Pulled it out of the rack, opened the case up, unplug the 2 cables, plugged them back in and triple checked that they were actually plugged in. I put the case on the floor, plugged in the video, keyboard and power cables and turned it on. When I go into the BIOS, bingo the hard drive is there. So, Murphy’s Law just proved after all these years of playing around with hardware, I can still do dumb things. D’oh!
I checked the specs for IBM MQ v9.1 and it is supported on RHEL 7.3 (or higher) and SLES 12 SP3 (or higher). In the 90’s and 2000’s, I only used Red Hat (Fedora) as the Linux OS for building and testing my applications, exits, etc. Around 7-8 years ago, I switched to SUSE as my primary Linux distribution for x86, x64, POWER and System Z because it seemed a lot of customers were using SUSE and IBM had it as their default Linux distribution for POWER and System Z VMs.. On Friday, I decided I would continue with SLES since I like using the system tool called YaST (Note: I’m not a SysAdmin).
Installing SLES was easy, the only odd part is that they seemed to have removed package selection after picking the type of usage you wanted (i.e. server, workstation, etc.). After the install, of course, a bunch of stuff was missing: gcc, ldap & pam development, plus a few other things. YaST to the rescue.
Created the mqm group, mqm UserId plus my UserId (add mqm group as additional group) and my testing UserIds.
I installed IBM MQ v9.1, Quest Authentication Services (aka Vintela Authentication Services), Centrify’s DirectControl and all of my tools. My fingers got tired of doing “rpm -ivh …”.
Next, I created my test queue managers and started them. Before I ever play around with my (Capitalware) security stuff, I make sure everything is working perfectly first. I start by feeding runmqsc the following MQSC commands:
ALTER QMGR CHLAUTH(DISABLED)
ALTER QMGR CONNAUTH(' ')
DEFINE CHANNEL ('SYSTEM.ADMIN.SVRCONN') CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
DEFINE LISTENER('LISTENER.TCP') TRPTYPE(TCP) CONTROL(QMGR) PORT(1414)
START LISTENER('LISTENER.TCP')
I started MQ Explorer, added the remote queue manager and when I connected, I got reason code 2035 (not authorized). I checked the /etc/group file and yes, my UserId was in the mqm group. The interesting thing I did not know, clearing/blanking CONNAUTH does not disable it. You have to either restart the queue manager or issue the following MQSC command:
REFRESH SECURITY TYPE(CONNAUTH)
Note: Before someone posts, “hey, why are you turning off MQ security”, it is because I going to be using MQAUSX which of is better than what comes with MQ. 🙂
Now that MQ Explorer and client tools like MQ Visual Edit can successfully connect to the new queue manager, I can move on to applying MQAUSX security solution.
Time to do some builds. GCC was chewing its way through the makefile then I get the following error:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: /tmp/cc13IfK2.o: undefined reference to symbol 'ber_free' /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/liblber-2.4.so.2: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status
WTF! I just used the very same makefile on the now dead SLES 11 SP2 64-bit server. After a bunch of searches, I found an explanation on StackOverflow about implicit vs explicit linking. What the above error message “DSO missing from command line” is trying to say (very badly) is that I need “-llber” on my GCC link step. Once I added to the makefile then GCC successfully compiled and linked everything in the makefile.
I have done some basic testing of my tools and security stuff and everything is looking good. Too bad I wasted 2 days because of a hard drive failure. 🙁
Regards,
Roger Lacroix
Capitalware Inc.
