Pad Kee Mao Gai

I created a separate cooking blog...

The blog writeup will move permanently here >

http://andresfernandezcooking.blogspot.com/


*************



I've been cooking Thai cuisine the last 2 years and have learned quite a few dishes.

I've done Lad Na, Pad Thai, Masaman, Pad Prik Khing, and other recipes, but wanted to try something new with Thai basil.

I order a lot from importfood.com, and wanted to use their recipe on the website but did a little more searching to see what the recipe would look like and see the possible variations.

I tried this recipe here : Alosha's Kitchen and with a couple of small modifications, I thought it was a very good recipe.

To keep the heat down to medium, I used only three Thai chilies along with 12 ounces of wide noodles and a pound of chicken. I did use a whole small red onion and a red and yellow pepper; so twice the amount of onion.

If you're using 12 ounces of wide noodles I would recommend a 1/4 cup of fish sauce, slightly a little less of the golden mountain and thick soy sauce and directly mix it with the chicken before putting it in the pan. I also mix my palm sugar with water for easy use and store it in the fridge so I can just pour it on the dish as I'm creating it.

Here's a photo of the finished dish :

Comparing UNIX networking commands : netstat, lsof and ss

I've realized recently there's a lot more availability in UNIX commands to look at your network (open ports, etc...).

Some sample commands that do the same thing, which I'll investigate later :

netstat -a -p  | grep 13100

ss -all | grep 13100

lsof -n -i4TCP | grep 13100

These three commands do a lot of similar things, albeit with some minor tweaks; and then pipe it to grep to look at a specific port.

Currently, my favorite for information and formatting is lsof.

I'll write more later...

The simplest resolution or explanation is usually the most common solution

In engineering, we have to diagnose and fix issues all the time.

In my case I've found that the problems I encounter when I find a build broken, a class that won't compile, or a problematic configuration that won't make a application run, is most likely due to a slight misconfiguration, misspelling, or not reading the directions thoroughly.

In other words, the easiest solution is usually the most common fix to a problem you've encountered.

Maybe this is why we have Occam's Razor as a principle?

Quick iptables setup to close off an outgoing IP for testing network interruption scenarios

I think for a lot of software testers these days, we have to test systems that span multiple servers.

Whether it's JGroups, 0MQ, or other messaging protocols, you have to make sure that systems behave correctly - or fail gracefully - when connections go down.

I posted about iptables before but it's good to review a couple of simple steps.

If I'm on a Linux system (like CentOS) I can test how a certain application might behave once it cannot connect to an external server.

If it's a simple system setup where you're testing just one application connection to another external application it's as easy as :

iptables -A OUTPUT -d [ip address] -j DROP

-A OUTPUT means to append to the OUTPUT chain (from this server to an external server)

-d is for the destination IP you want to block

-j is for jump target. If a packet matches what was stated for -A and -d then what should iptables do? In this case, I'm adding this packet to the DROP chain.

and...when I'm done testing and need to reenable communication to that IP,

iptables -F

Solving 'Plugin org.apache.maven.plugin could not be found', or 'Could not find artifact in artifactory-release'

We recently purchased an Artifactory 3.4 pro license where I work, and I've been setting it up to work with Jenkins.

Unfortunately, Jenkins was failing when it was trying to download an Apache Maven dependency with a virtual repository I'd created.

Either I'd forgotten a step or it'd been already setup when I'd been playing with the evaluation version, but I'd failed to link a huge online maven 2 repository to my virtual repo.

[NOTE: I was also trying to update the .m2/settings.xml file and that wasn't working either in Jenkins. ]

If you're getting messages in your Jenkins console output like this :

[ERROR] Plugin [...] or one of its dependencies could not be resolved: Failed to read artifact descriptor for [...]: Could not find [...] in artifactory-release

and have setup your Jenkins job (AKA job) to work with Artifactory, this might be the issue.

Once I had my virtual repository serving artifacts from my local repository, I failed with adding a remote repository - and one of the most crucial : maven2.

In my case  org.apache.maven.plugins:maven-clean-plugin:2.5, wasn't found.

I added a new remote repository pointing to : http://repo.maven.apache.org/maven2/

Then I went back to my virtual repo and added the Maven repo under Edit Virtual Repository > Basic Settings > Repositories.

I launched the build again and the error went away.

Running nmap scans to verify services aren't disrupted (e.g. elasticsearch)

I've worked in the software security space for about 5 years now, both in identity management and now SIEM/log analytics.

One useful UNIX command I never had experience with - until now - was nmap.

A big problem that we've encountered has been some services that work with elasticsearch were easily disrupted by external nmap scans.

To remedy this we had to reduce the number of externally accessible ports and also use nginx as a reverse proxy that would make people log into our web interfaces with a username and password.

NMAP:

There seem to be non-intrusive and more intrusive versions of nmap, to test what ports are open on a remote server and also more aggressive scanning and faster execution, respectively.

Some sample comands:

nmap -p 1-65535 [IP of server]
nmap -p [port range],[another individual port if needed] -T4 -A -v [IP of server]

These commands were definitely helpful when trying to verify the lock down of our ports; especially with some services like elasticsearch and cassandra. Additionally putting nginx in front of web browser services (e.g. elasticsearch HQ) that helped out even more.

nmap is certainly a nice tool for testing port lockdown.

Pesky SSH KnownHosts file (WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!)

I posted earlier in the year about SSH reverse tunneling.

At my new job, I haven't had as many issues in that department but I do re-image servers quite a bit and then need to SSH back into the machine and get those pesky errors informing me there might be a man-in-the-middle attack. Well, this is an internal firewalled server, so that's extremely unlikely.

When this happened I started off by runing ssh-keygen -R[hostname|IP address]

and that worked well, but if you by chance have more than one known_hosts file under your .ssh it might not work.

When that became a little more tedious I tried just deleting the known_hosts* file(s) under .ssh. That worked too, but it's a little too much for the task at hand. Kinda like taking a sledgehammer to a small problem.

I ultimately decided that I wanted something a little less severe that would tackle the short-term problem. The best solution is to pass command line arguments when you SSH.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@[hostname|IP address]

I found a few sites that mentioned this but, it was Linux Commando who provided good detail. Thanks.

Since I was also doing SSH scripting with Perl, I though I would add a step to my script to wait for the SSH daemon to start after a re-image/reboot.

Here's the code, and it was a little more difficult to get to work since I don't work with Perl as regularly (although more recently) and the Net::SSH::Perl documentation could offer a few more examples of how to setup the options.

Here's the code :

eval

                {

                        my %params;

                        $params{"strict_host_key_checking"} = "no";

                        $ssh = Net::SSH::Perl->new($passedHost, %params, options => ["UserKnownHostsFile /dev/null"] );

                        $ssh->login($user, $pass, %params);

                };

                if ($@) {

                warn "Cannot SSH yet. Here's the error message below:\n$@Waiting 30 seconds for SSH daemon to come up.\n";

                }

                sleep 30;