Short post in case anyone has the same product.
Bought a Corsair VOID RGB headset at $180, looks and sounds great! http://www.corsair.com/en-us/landing/void
I'd be playing music and suddenly I'd get my microphone beeping red rapidly, and a few seconds later it'd just shut off. I'd turn it on again and the side lights wouldn't go on...
I saw a setting on the CUE control panel called "Disable auto shutoff" disabled, which I find really weird for a default setting. Anyway I've now enabled it, hopefully I don't face the issue anymore!
Wednesday, January 27, 2016
Thursday, January 21, 2016
Setting up webserver on RasPi
This shouldn't have been a headache, but it sure was!
The idea was:
1. Get a domain
2. Put my site content on RasPi
3. Profit
I'd recently moved to Singapore from Australia, so naturally a new router. I'm actually surprised by the amount of changes I needed to move from my previous DLink router to the new DLink router. Anyway this is what I ended up having:
I'd actually struggled with stability with the RasPi. The keywords are "wireless-power off". The /var/logs/network said nothing about power saving...
So I go on to buy a domain off NameCheap, and learn a thing or two about CNAMEs. Hence I create one that points to my IP...oh hang on, I need a static IP which typically means I need to pay my ISP a few more dollars...lets not.
I set up NoIP and use their dynamic IP updater so I can set a hostname which points to my dynamic IP. This is where I then realize my ISP has some paranoia issues and blocked port 80! No problem, I'll setup a URL Redirect record in NoIP, then on NameCheap my CNAME can point to this URL Redirect. If only it were that simple, it doesn't look like CNAMEs can point to URL Redirects, not quite sure why this doesn't work...
Luckily, NameCheap have their own dynamic IP updater which I hadn't realized earlier, so I scrap the NoIP idea. This creates an A+ dynamic DNS record which points to my dynamically updated IP. Unfortunately, this still means I can't use port 80, because CNAMEs don't accept ports, and neiher does the dynamic IP updater...I've decided to live with specifying ports for now.
The idea was:
1. Get a domain
2. Put my site content on RasPi
3. Profit
I'd recently moved to Singapore from Australia, so naturally a new router. I'm actually surprised by the amount of changes I needed to move from my previous DLink router to the new DLink router. Anyway this is what I ended up having:
auto lo
iface lo inet loopback
iface eth0 inet dhcp
wireless-power off
allow-hotplug wlan0
auto wlan0
iface wlan0 inet manual
wireless-essid 'MyInternetz'
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface home inet static
address 192.168.0.250
netmask 255.255.255.0
network 192.168.0.0
gateway 192.168.0.1
iface default inet dhcp
I'd actually struggled with stability with the RasPi. The keywords are "wireless-power off". The /var/logs/network said nothing about power saving...
So I go on to buy a domain off NameCheap, and learn a thing or two about CNAMEs. Hence I create one that points to my IP...oh hang on, I need a static IP which typically means I need to pay my ISP a few more dollars...lets not.
I set up NoIP and use their dynamic IP updater so I can set a hostname which points to my dynamic IP. This is where I then realize my ISP has some paranoia issues and blocked port 80! No problem, I'll setup a URL Redirect record in NoIP, then on NameCheap my CNAME can point to this URL Redirect. If only it were that simple, it doesn't look like CNAMEs can point to URL Redirects, not quite sure why this doesn't work...
Luckily, NameCheap have their own dynamic IP updater which I hadn't realized earlier, so I scrap the NoIP idea. This creates an A+ dynamic DNS record which points to my dynamically updated IP. Unfortunately, this still means I can't use port 80, because CNAMEs don't accept ports, and neiher does the dynamic IP updater...I've decided to live with specifying ports for now.
Tuesday, January 5, 2016
What I find wrong with MacOS
Just a rant. Since using a Mac I question why all the hype about using Macs over Windows. There are interface problems that persist that no one is reviewing and irritate the hell out of me. And then some problems are probably just personal preference...
- On Date & Time preferences, why do I need to "unlock to make changes", and then untick "Set date and time automatically" (which lags by the way), just to view other months on my calendar?
- If for some reason a script on my browser takes awhile to run, my cursor clicks go mental. E.g. if I click on a file to rename it, Mac immediately unfocuses my highlight, so quickly that I can't rename my file. Or if I highlight a file, I lose my highlight almost immediately. There must be something wrong with the multi-threading...
- When I minimize a window, why does a new window get created in my dock?
- Can't resize images in Outlook. Microsoft hurry up with the update.
- The closest thing to a Notepad++ (free text editor) I could find for Mac is Brackets, which is lacking alot of features.
- Fn+F11 is NOT how I want to shimmy to Desktop (given minimizing is not an option either), give me a handy button in the Dock.
- Opening programs in the Dock require only a single-click to open. So I get alot of misfires and get frustrated.
- Format Painter in Microsoft products on Mac are on the top, but on Windows it's in the ribbon. This is more a Microsoft inconsistency issue...
- If I drag a file into a folder on Finder, please put it into that folder, NOT the folder I am currently in. Jeez!
- Scrolling horizontally requires 2 fingers to drag horizontally, which is great, except on a browser this pushes me back a page as well.
- Volume keys randomly stop working. I get the 'restricted' sign instead. "sudo killall coreaudiod" fixes this. What on earth?
Thursday, November 20, 2014
Splunk & Spring Integration
Today's headache is integrating the two!
Me, having limited Spring experience, embarked on a wild journey of bean definitions and namespace resolutions, it got really frustrating before enjoyable...
Referencing http://docs.spring.io/autorepo/docs/spring-integration-splunk/0.5.x-SNAPSHOT/reference/htmlsingle/, it seems easy. Add this and you're set, or are you?
Well no, because going to http://www.springframework.org/schema/integration/splunk yields nothing. I'd wish Spring mentions that!
You must add this to your dependencies:
http://maven-repository.com/artifact/org.springframework.integration/spring-integration-splunk/1.1.0.RELEASE
Cool so for me, I'm using IntelliJ, and Ivy for my dependency management. Keep in mind IntelliJ Community Edition has no Spring support, thought I'd mention that because my Intellij was complaining about Spring being an "unknown facet". Also, I'm running my application on Jetty.
It should just work, but I continually got this:
Caused by: org.springframework.beans.FatalBeanException: Class [org.springframework.integration.splunk.config.xml.SplunkNamespaceHandler] for namespace [http://www.springframework.org/schema/integration/splunk] does not implement the [org.springframework.beans.factory.xml.NamespaceHandler] interface
What does this even mean? After lots of googling, I was led to believe I had a classloader issue. Do I add an entry to my web.xml, or my project classpath? Do I add my JAR to my WEB-INF/lib folder (worst suggestion ever)? But everything in my IntelliJ lib folder is already on the classpath!! Then I thought, hm maybe the error means something and it's because SplunkNamespaceHandler is extending AbstractIntegrationNamespaceHandler...
Nope, none of the above. The problem is the Splunk JAR (1.1.0) has a dependency on 4.0.2-RELEASE of Spring, whereas my Spring context.xml looked like the below:
Changing all the Ivy dependencies to 4.0.2 and making sure IntelliJ's default Spring libraries aren't being used did the trick.
Also, my perfect girlfriend asked for a shoutout, so here it is! :)
Me, having limited Spring experience, embarked on a wild journey of bean definitions and namespace resolutions, it got really frustrating before enjoyable...
Referencing http://docs.spring.io/autorepo/docs/spring-integration-splunk/0.5.x-SNAPSHOT/reference/htmlsingle/, it seems easy. Add this and you're set, or are you?
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:int="http://www.springframework.org/schema/integration"
xmlns:int-splunk="http://www.springframework.org/schema/integration/splunk"
xsi:schemaLocation="http://www.springframework.org/schema/integration/splunk
http://www.springframework.org/schema/integration/splunk/spring-integration-splunk.xsd
http://www.springframework.org/schema/integration
http://www.springframework.org/schema/integration/spring-integration.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
</beans>
Well no, because going to http://www.springframework.org/schema/integration/splunk yields nothing. I'd wish Spring mentions that!
You must add this to your dependencies:
http://maven-repository.com/artifact/org.springframework.integration/spring-integration-splunk/1.1.0.RELEASE
Cool so for me, I'm using IntelliJ, and Ivy for my dependency management. Keep in mind IntelliJ Community Edition has no Spring support, thought I'd mention that because my Intellij was complaining about Spring being an "unknown facet". Also, I'm running my application on Jetty.
It should just work, but I continually got this:
Caused by: org.springframework.beans.FatalBeanException: Class [org.springframework.integration.splunk.config.xml.SplunkNamespaceHandler] for namespace [http://www.springframework.org/schema/integration/splunk] does not implement the [org.springframework.beans.factory.xml.NamespaceHandler] interface
What does this even mean? After lots of googling, I was led to believe I had a classloader issue. Do I add an entry to my web.xml, or my project classpath? Do I add my JAR to my WEB-INF/lib folder (worst suggestion ever)? But everything in my IntelliJ lib folder is already on the classpath!! Then I thought, hm maybe the error means something and it's because SplunkNamespaceHandler is extending AbstractIntegrationNamespaceHandler...
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:task="http://www.springframework.org/schema/task"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:int-splunk="http://www.springframework.org/schema/integration/splunk"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/integration/splunk
http://www.springframework.org/schema/integration/splunk/spring-integration-splunk.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.1.xsd
http://www.springframework.org/schema/task
http://www.springframework.org/schema/task/spring-task-3.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd">
Changing all the Ivy dependencies to 4.0.2 and making sure IntelliJ's default Spring libraries aren't being used did the trick.
Also, my perfect girlfriend asked for a shoutout, so here it is! :)
Monday, October 20, 2014
Packer, Vagrant and Windows
Fun day of setting up Packer with configurations my colleague put together :)
Packer is a way for you to build a Vagrant box locally with all the software and configurations you need, without having to transfer an enormous VBox around. Very neato.
On running a simple "packer build", your OS should build from scratch. First problem I encounter:
More info here
The executable 'bsdtar' Vagrant is trying to run was not
found in the %PATH% variable. This is an error. Please verify
this software is installed and on the path.
What do you expect I'd do? I locate bsdtar.exe in "C:\HashiCorp\Vagrant\embedded\mingw\bin", and add the path to my PATH. Then I get another error:
Well that was useless. Long story short, it seems like a bug when upgrading Vagrant from an older version to a newer version. I upgraded from 1.6.3 to 1.6.5. Uninstalled my current and reinstalling Vagrant 1.6.5 fixed the issue.
Getting past the intial setup, we wrote scripts to automate installation of a particular IBM product: Maximo. Here's some of the dependencies:
Packer is a way for you to build a Vagrant box locally with all the software and configurations you need, without having to transfer an enormous VBox around. Very neato.
On running a simple "packer build
More info here
The executable 'bsdtar' Vagrant is trying to run was not
found in the %PATH% variable. This is an error. Please verify
this software is installed and on the path.
What do you expect I'd do? I locate bsdtar.exe in "C:\HashiCorp\Vagrant\embedded\mingw\bin", and add the path to my PATH. Then I get another error:
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and try again. The
output from attempting to unpackage (if any):
x Vagrantfile
x box.ovf
x metadata.json
x ubuntu1404-disk1.vmdk: Write failed
Packer/bsdtar.EXE: Error exit delayed from previous errors.
file you're trying to add is not corrupted and try again. The
output from attempting to unpackage (if any):
x Vagrantfile
x box.ovf
x metadata.json
x ubuntu1404-disk1.vmdk: Write failed
Packer/bsdtar.EXE: Error exit delayed from previous errors.
Well that was useless. Long story short, it seems like a bug when upgrading Vagrant from an older version to a newer version. I upgraded from 1.6.3 to 1.6.5. Uninstalled my current and reinstalling Vagrant 1.6.5 fixed the issue.
Getting past the intial setup, we wrote scripts to automate installation of a particular IBM product: Maximo. Here's some of the dependencies:
- Install WebSphere Application Server or Oracle WebLogic, ~2-3GB
- A database (I used Oracle 11g R2), minimalistically this takes about 5-10GB space
- Yum packages (e.g. Ant, Oracle DB pre-reqs)
- Open File descriptors, kernel property changes
- Running maxinst.sh
- The documentation suggests using a post processor to keep "intermediary artfacts" (the vbox) like so:
"post-processors": [ { "output": "builds/centos65-wwm-base.box", "type": "vagrant", "keep_input_artifact": true } ]
The trouble is, I still get "Deleting output directory" at the end of a failed build, which means "keep_input_artifact" only works if your build succeeds (I'm guessing, I never tried). Horrible stuff, you're going to automatically delete 3 hours worth of builds with no way for me to keep my vbox? Not happy HashiCorp. - I like to lock my screen while stuff runs in the background. With Packer? Bad idea.
Wednesday, October 8, 2014
SoapUI working with IBM JRE
In short: there is no support from Smartbear to support the IBM JRE, all efforts lead to a response of "use the Sun JRE".
Why would you use the IBM JRE? This is to send JMS messages to WebSphere's SI Bus, where the Application Server has Global Security turned on. You are required to set these 2 JVM properties:
-Dcom.ibm.CORBA.ConfigURL
-Dcom.ibm.SSL.ConfigURL
If you don't do this and attempt to send a message, you get a WsnInitialContext exception.
Once you've configured soapui-pro.sh to use the IBM JRE, you'll find that you won't be able to activate/use your license (even if you'd activated it while using the Sun JRE). You'll go through the process of re-activating your license, but be told you're missing a valid license.
After a day's effort of trying different things, such as moving across Sun's JRE providers into IBM JRE's "java.security" file, I ended up decompiling soapUI's code. It appears soapUI's decryption method is "RSA - SunJCE - 512", which requires the "BouncyCastle" security provider. The solution was to add this line to the JRE's java.security file:
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
Voila, you can now activate your license. Although...
SoapUI Pro 5.1.2 has a gotcha when running testrunner.sh. It will attempt to validate your license as well, and requires you to have X11 forwarding enabled (no matter what). So if you're like me and are running SoapUI Pro on a headless Linux environment, you're stuffed. We ended up downgrading to 5.0.0, where this X11 port forward is not required.
Why would you use the IBM JRE? This is to send JMS messages to WebSphere's SI Bus, where the Application Server has Global Security turned on. You are required to set these 2 JVM properties:
-Dcom.ibm.CORBA.ConfigURL
-Dcom.ibm.SSL.ConfigURL
If you don't do this and attempt to send a message, you get a WsnInitialContext exception.
Once you've configured soapui-pro.sh to use the IBM JRE, you'll find that you won't be able to activate/use your license (even if you'd activated it while using the Sun JRE). You'll go through the process of re-activating your license, but be told you're missing a valid license.
After a day's effort of trying different things, such as moving across Sun's JRE providers into IBM JRE's "java.security" file, I ended up decompiling soapUI's code. It appears soapUI's decryption method is "RSA - SunJCE - 512", which requires the "BouncyCastle" security provider. The solution was to add this line to the JRE's java.security file:
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
Voila, you can now activate your license. Although...
SoapUI Pro 5.1.2 has a gotcha when running testrunner.sh. It will attempt to validate your license as well, and requires you to have X11 forwarding enabled (no matter what). So if you're like me and are running SoapUI Pro on a headless Linux environment, you're stuffed. We ended up downgrading to 5.0.0, where this X11 port forward is not required.
Monday, August 25, 2014
Maximo startup problems!
Our infrastructure utilizes WebSphere MQ as our Maximo queue backend. Our automation framework (consisting mainly of jython scripts injected into wsadmin) sets up CQIN and SEQIN queues, as well as activation specifications and whatnot, with 1 click of a button, so our margin for error is pretty low once it's off the ground running.
So when this error appeared in SystemOut.log on Maximo startup it was quite discomforting:
[8/25/14 15:53:39:542 EST] 000003d9 SystemOut O 25 Aug 2014 15:53:39:510 [ERROR] [MXServer] [] java.lang.NullPointerException at psdi.iface.jms.JMSContQueueProcessor.processMessage(JMSContQueueProcessor.java:253) at psdi.iface.jms.JMSListenerBean.onMessage(JMSListenerBean.java:203) at com.ibm.ejs.container.WASMessageEndpointHandler.invokeJMSMethod(WASMessageEndpointHandler.java:138) at com.ibm.ws.ejbcontainer.mdb.MessageEndpointHandler.invokeMdbMethod(MessageEndpointHandler.java:1146) at com.ibm.ws.ejbcontainer.mdb.MessageEndpointHandler.invoke(MessageEndpointHandler.java:844) at com.sun.proxy.$Proxy33.onMessage(Unknown Source) at com.ibm.mq.connector.inbound.MessageEndpointWrapper.onMessage(MessageEndpointWrapper.java:131) at com.ibm.mq.jms.MQSession$FacadeMessageListener.onMessage(MQSession.java:125) at com.ibm.msg.client.jms.internal.JmsSessionImpl.run(JmsSessionImpl.java:2747) at com.ibm.mq.jms.MQSession.run(MQSession.java:950) at com.ibm.mq.connector.inbound.ASFWorkImpl.doDelivery(ASFWorkImpl.java:88) at com.ibm.mq.connector.inbound.AbstractWorkImpl.run(AbstractWorkImpl.java:216) at com.ibm.ejs.j2c.work.WorkProxy.run(WorkProxy.java:668) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1862)
So when this error appeared in SystemOut.log on Maximo startup it was quite discomforting:
[8/25/14 15:53:39:542 EST] 000003d9 SystemOut O 25 Aug 2014 15:53:39:510 [ERROR] [MXServer] [] java.lang.NullPointerException at psdi.iface.jms.JMSContQueueProcessor.processMessage(JMSContQueueProcessor.java:253) at psdi.iface.jms.JMSListenerBean.onMessage(JMSListenerBean.java:203) at com.ibm.ejs.container.WASMessageEndpointHandler.invokeJMSMethod(WASMessageEndpointHandler.java:138) at com.ibm.ws.ejbcontainer.mdb.MessageEndpointHandler.invokeMdbMethod(MessageEndpointHandler.java:1146) at com.ibm.ws.ejbcontainer.mdb.MessageEndpointHandler.invoke(MessageEndpointHandler.java:844) at com.sun.proxy.$Proxy33.onMessage(Unknown Source) at com.ibm.mq.connector.inbound.MessageEndpointWrapper.onMessage(MessageEndpointWrapper.java:131) at com.ibm.mq.jms.MQSession$FacadeMessageListener.onMessage(MQSession.java:125) at com.ibm.msg.client.jms.internal.JmsSessionImpl.run(JmsSessionImpl.java:2747) at com.ibm.mq.jms.MQSession.run(MQSession.java:950) at com.ibm.mq.connector.inbound.ASFWorkImpl.doDelivery(ASFWorkImpl.java:88) at com.ibm.mq.connector.inbound.AbstractWorkImpl.run(AbstractWorkImpl.java:216) at com.ibm.ejs.j2c.work.WorkProxy.run(WorkProxy.java:668) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1862)
This error was flooding the logs every few milliseconds, and causing CPU starvation!
It seemed to suggest the "JMSContQueue" was trying to "processMessages" (duh). The problem: The WebSphere MQ infrastructure (which we didn't own) did not have the queue yet. For some reason Maximo polls infinitely for the queue...so I changed "intjmsact" to point at a queue which did exist, and voila!
But that wasn't the end of it! When the queue was finally created and "intjmsact" was configured back to point at the original queue, same error message!
This time, the problem was that there were messages already on the queue, which Maximo did not recognize. Maximo picked them up, rejected them, and put them back on the queue, causing yet another infinite cycle. Deleting the messages resolved the issue.
Subscribe to:
Posts (Atom)