Making it work: WECUBE 27″ LED ST2770W Monitor and a Retina MacBook Pro

Posted on January 7, 2013 by behl@webscaling.com

After getting a 15″ Retina MacBook Pro (or “rMBP” as I see them referred to as) and being awed by the real estate offered by the retina screen (I use the scaled 2880X1800 resolution), I wanted an external monitor that came somewhat close to this. 1920 X 1200 is nice, but it’s just nowhere near the MBP retina resolution, which is particularly vexing considering how much larger the external displays are. Looking around I saw a number of $600-700 displays with 2560×1440 resolutions, but that’s just more than I wanted to spend (and certainly makes me think the MBP is a good deal considering you get such a high resolution screen AND a computer!).

Reading reviews of IPS monitors on AnandTech I saw in the discussions mention of a crop of cheap monitors out of South Korea with 2560×1440 resolution, offered out of eBay.  Slightly sketchy sounding, but having found such a monitor on eBay for only $380 with free shipping, I couldn’t resist:

WECUBE ST2770W LED IPS 27″ 2560×1440 WQHD HDMI PC Monitor

I received it 3 days later (amazing as it was shipped from South Korea), and while it’s definitely South Korean (read:  menu system and manual is in Korean), the screen is gorgeous for my needs (DevOps stuff…lots of browser and terminal windows).  The one catch which made this story almost have a very sad ending:  getting it to work with a MacBook Pro.  So to spare others the pain and suffering:

You cannot get the full 2560×1440 resolution via HDMI (but don’t worry, you’re not sunk!)

2560×1440 via HDMI doesn’t work…won’t happen.  The highest you can get is 1920×1200.  My reading seems to indicate that this is NOT because of a hardware limitation on either the monitor or on the MacBook Pro, but rather OS X itself.  The reason I say this is others have reported that, using bootcamp and running Windows,  you get the full 2560×1440 just fine via HDMI.  Now isn’t that weird.

You CAN get 2560×1440 but you need to pony up $80 to get a displayport to dual-link DVI adpater

You can use a generic one

http://www.monoprice.com/products/product.asp?seq=1&format=2&p_id=6904&CAWELAID=1329453866&cagpspn=pla

or pay more for Apple’s (what I did by walking over to the Apple store as I didn’t want to wait)

http://store.apple.com/us/product/MB571Z/A/mini-displayport-to-dual-link-dvi-adapter

BUT you need to make sure you have a dual-link DVI cord!

News to me, but the DVI cable you have lying around is probably single-link (read up on the exciting world of DVI to learn more).  I didn’t know there was such a think, but after trying to use the DVI cable I had been using for my existing monitor (not the one that came with the WECUBE), the screen would go through repeated contortions/flickers (completely unreadable).  It’s really not what I would expect to see with the wrong cable (I’d of thought it just wouldn’t work), but what you see makes you think you have a bad monitor or adapter.  But as mentioned, the WECUBE does come with the correct cable.  Using the Wikipedia article on DVI you can look at the pins on your DVI cable to see what kind it is.

So end of story:  nice big high resolution 27″ monitor!  Woo hoo!  DevOps perfection!

 

 

 

Posted in hardware | Leave a comment

puppet – using apache as the file server for tomcat install

Posted on September 19, 2011 by behl@webscaling.com

Often times it seems you need to unarchive a tarball onto a new system, and it’s nice to have puppet in charge of dealing with new systems, but it’s not nice to have:

  1. puppet be the one serving the large file
  2. puppet going through a two step process of downloading the archive and then unarchiving it

To address 1) I configured Apache on the same machine as puppet and have it serve the files.   Please note that all security considerations have not been thought through here, but I think it’s sufficient for an internal host.

Assuming puppet is installed into “/etc/puppet”, I used the following in httpd.conf:

AliasMatch ^/puppet/(.*)/(.*)$ /etc/puppet/modules/$1/files/$2

This makes it so each module can have files in the files/ directory served via apache.

Part two of this is actually doing the unarchive operation inline.  For that I created a definition:

$puppet_http_server = "srv1.mydomain"

define untar($archive = "${name}",$path,$creates,$module = "${caller_module_name}") {

        exec {"curl http://${puppet_http_server}/puppet/${module}/$archive | tar -xzf - ":
                cwd     => $path,
                creates => "${path}/${creates}"
        }
}

So how to use this?  Here’s an example generic tomcat installation.  It relies on the “apache-tomcat-5.5.33.tar.gz” archive (downloaded directly from the tomcat site) being in the modules “files” dir:

puppet/modules/tomcat5_5_33/files/apache-tomcat-5.5.33.tar.gz

class tomcat5_5_33() {

	$version = "5.5.33"

	# creates /usr/local/apache-tomcat-$version
	#
	$path		= "/usr/local"
	$dir 		= "apache-tomcat-${version}"
	$archive	= "${dir}.tar.gz"

	#custom  resource definition from site.pp
	untar {"$archive":
		path	=> $path,
		creates	=> $dir
	}

}

The end result is an installed version of tomcat in:

/usr/local/apache-tomcat-5.5.33

It’s done on the fly and won’t unarchive again unless the directory is gone.

The same can be done for arbitrary rpms as well via this define:

define rpm_http($rpm = "${name}",$creates,$module = "${caller_module_name}") {

	exec {"rpm -i http://$puppet_http_server/puppet/${module}/${rpm}":
		creates	=> "$creates"
	}

}

Hope this helps!

Posted in puppet | Leave a comment

absolute simplest way to install puppet on CentOS 5.5 or 5.6

Posted on May 1, 2011 by behl@webscaling.com

if you aren’t using configuration management you’re not really a sysadmin and shouldn’t be in charge of more than a single linux box. so considering myself a real sysadmin (or when I feel like sounding more important, an “Infrastructure Architect” sorta like the ring of that) i use and love puppet.

unfortunately the EPEL repo always seems to be far behind in terms of the latest available puppet version, so i went the gem route. For the latest version, go here: http://puppetlabs.com/downloads/gems/. The below is using 2.6.8

rpm -ihv http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
yum -y install rubygems ruby-augeas ruby-shadow libselinux-ruby facter

wget http://puppetlabs.com/downloads/gems/puppet-2.6.8.gem
gem install --no-rdoc --no-ri puppet-2.6.8.gem

# remove --no-daemonize and --verbose below if you want them to run in the background, but I recommend leaving each running in its own separate window in the foreground until you understand what's going on
#
# on the master
puppet master --no-daemonize --verbose --mkusers

# on the client
puppet agent --no-daemonize --verbose --mkusers --server <above_server_dns_name>

And that’s it. The only thing missing from the above is an init script but you can just snag that from the RPM of the older version.

Posted in CentOS, puppet | Leave a comment

linux interface bonding and why the default setting is screwed (you need to set arp_validate)

Posted on March 18, 2011 by behl@webscaling.com

I didn’t realize the need for arp_validate until recently as, in the past, my boxen have always been connected to a layer-3 switch (Cisco 3560) which was both the distribution switch and the router (they are superb devices in this regard) .  Either call me simple or a small environment guy (both of which have a decent amount of validity), but up until I had another layer of switches (to be describe below), I didn’t bother reading up on arp_validate.

In general, linux interface bonding has been dreamy and worked wonderfully.  I’ve only used it in active/passive mode (no link aggregation ), but in this configuration it’s worked flawlessly…up until I purchased some Dell M1000E switches with integrated Cisco 3130X  switches.  For the record, I’ve been waiting ages for the Cisco integrated switches to become cost effective, and within the last few years, they have been.  The 3130X is basically a Catlayst 3560X switch from my understanding, and for me, this was exactly what I wanted…who wants to deal with passthrough modules?  On blade switches, what’s the point?  It takes away a decent part of the reason for getting blades and blade chassis in general…

But getting back to the interface bonding…I went with the normal default settings of have an arp_ip_target of the default gateway (HSRP address of two 3560s in our case) and an apr_interval of 500ms.  Admittedly I should have read up more on what the arp_validate was good for I guess, but the default value for it is 0, or no validation (see http://www.mjmwired.net/kernel/Documentation/networking/bonding.txt#275), is asinine imho.  Basically the module  doesn’t care if the arp_ip_target is the one sending back an answer to your arp request!  Any incoming arp request will suffice, even if it’s generated by another host connected to the same switch, or even the backup interface.  That’s just crazy talk in my mind.  When your distribution switch is your router as well (which is often the case in the setup I’ve done where a 3560 cluster acts as both) this wasn’t a problem:  the switch goes down, and so goes down your arp_ip_target (the default gateway), as well as the actual port.  But…add in integrated switches into your blade chassises that are connected to your routing later (via an etherchannel trunk in my case), and voila!  You have a distribution layer.  If your layer 3 device goes down, the bonding interface still sees arps coming in via the integrated switch (distribution layer) and thinks all is good.  Why it would think things are fine when the arp it generates isn’t answered…I don’t get it, but this seems to be the case (read the above doc).  The pertinent snippet:

311		This option is useful in network configurations in which
312		multiple bonding hosts are concurrently issuing ARPs to one or
313		more targets beyond a common switch.  Should the link between
314		the switch and target fail (but not the switch itself), the
315		probe traffic generated by the multiple bonding instances will
316		fool the standard ARP monitor into considering the links as
317		still up.  Use of the arp_validate option can resolve this, as
318		the ARP monitor will only consider ARP requests and replies
319		associated with its own instance of bonding.

I’ll say it’s useful.  It has to be a screwball config where it’s not useful?!  I’m sure there’s a case somewhere, but it doesn’t come to mind immediately, please feel free to comment..

So moral of the story?  There’s no reason, when using arp_ip_target, not to set arp_validate=3.  It can only hurt you.

 

Posted in Uncategorized | Tagged , , | Leave a comment

MongoDB training – day 2

Posted on October 1, 2010 by behl@webscaling.com

I can’t remember at this point (non-google translation:  I just got back from the bars and am unwilling to look up what I wrote earlier) if I mentioned that the track I’m on is for “system administrators,” or at least something similar.  But it is, for what that’s worth.  In any case…

Take-aways from day 2…

Day two started with replica sets.  Replication in Mongo is, without question, part of normal operations.  ”slaves” are not special beasts only needed to make sure you have a backup of your data nor to make sure you can scale as read-only data sources, they are absolutely critical and  part of normal business operations.   Why?  Well, as stated earlier in both “MongoDB is webscale” and as freely admitted by anybody at Mongo, Mongo does not write to disk.  Period.  kill -9 is the same as machine crashing is the same as..whatever it takes for Mongo to go down in non-normal exit.  While I’m reiterating this again, it isn’t by any means to bash.  Mongo is fast as hell, and this is what you pay to get it that fast.  And as I stated earlier (I think), it forces replicas, which is a “good thing” (at least provided that Mongo doesn’t crash on itself, which I have no idea about as I haven’t run it yet in production).  What this means to me as the guy that has to help spec out hardware and what not (either in the current data centers or in Amazon) is:  what sort of hardware should I use.  For physical hardware (Dell, in our case) this means there’s not really much point in paying the premium for a RAID-10 setup.  If a database or OS crash means I’ll have to completely re-create a slave from scratch (a crash leaves the DB in a non-recoverable state), than the same holds true for a disk failure.  As all of you should be, re-creating a box should be “normal” and not require much work.  In our case, this is accomplished by a combination of PXE boot and puppet.  To get any particular machine back to the state where it’s again a Mongo replica is going to require transferring over the entire database to it.  The added extra time in re-imagine the machine from PXE boot and puppet isn’t that much more.  So given this and going with the Mongo provided notion that “nodes are ephemeral”, why spend the extra money on anything other than RAID-0.  That’s at least my current thinking.  You get all the storage sub-system speed (for the most part) of RAID-10 at half the cost.

Now concerning slaves/replicas.  There are some decisions to be made here.  From what I took in from the class, a driver can be set to be “replica set aware” or not.  From what I understand, a driver will always pick the master for all operations.  While this may change at some point, currently this is the case.  The advantage of this is that if your master fails, an election for the new master will be held and your driver will follow it.  Nice.  At least for writes.  But if you’re looking to use the slaves for performance needs (and if we’ll ever need this…I’ve no idea…engineering doesn’t really deign to inform us of their needs in terms of actual numbers), then you’ll want to use replicas for read operations…right?  So the way to do this is behind a load balancer while setting the driver to be non-replica-set aware and to have multiple connections:  one for rw and the other for ro.  The ro connection could presumably be behind a load balancer.  There’s more to this in that the load balancer should check for delay, but this is for a later discussion.

There’s more from day two I’d like to comment on but right now as it’s time to go for reasons that shall beyond the scope of this blog.  To be continued…

Posted in Uncategorized | Leave a comment

MongoDB training – day 1

Posted on September 29, 2010 by behl@webscaling.com

Griffon Hotel…not so bad, though the room’s window looks into the bowels of the building.   SF has been ridiculously warm and beautiful…I thought it was supposed to be cold and gloomy?!  A nice run up to Ft. Mason was delightful after class.

The class is geared towards sysadmins/ops folk, but half the day was spent going through basic CRUD with Mongo.   The class is ~12 people with attendees equally spread out among small startups, larger corporations, and a few well known tech companies.  Some have deployed already, but most are learning what it’s all about.  I’m decidedly in the latter camp, having installed the database that morning on my Mac (we were supposed to have installed it for the class but that email went out the night before and I missed it).  And by install I mean unarchive a tarball grabbed from the MongoDb website.   They have statically compiled archives for many architectures…

There was some griping about certain distros packaging of Mongo (Ubuntu and some missing libraries), but I’m not one much for installing distro provided packages when they’re already available from the developers.  I’m distro agnostic…I just don’t care as long as it’s stable and has a decent repository system for updates and common packages.

So..what the hell is MongoDB.  A few of my first impressions as it’s too late to go into detail…

JSON JSON JSON…it’s all about JSON.  If you are going to be dealing with MongoDB (querying data and navigating around int he database) you very well may have a leg up by being a developer rather than a MySQL admin.  A good knowledge of data structures and object oriented semantics goes a long ways.  Everything stored in it is a JSON object.  If you don’t know what that is go look it up else you’ll be lost.   This is not a relational database, it doesn’t resemble one at all. It’s a different beast, it stores objects.  There are no joins.  There are no transactions, though there are levels of atomicity on per-object operations.

There’s no such thing as running it in production on only a single machine.  There are NO GUARANTEES (capitalized as our instructor re-iterated 5 times) that data will be on disk if you kill -9 the process, lose power, have a crash, etc.  If any of things things happen, you can expect to lose data.  Expect it!  MongoDB must be be run with at least one slave, and hopefully more.  However, CRUD operations can be made to not return until the master has verified that the operation has been replicated to a configurable number of slaves.  Save you have a master and 3 slaves.  You can mandate that the operation not return until at least two of the slaves have a copy of the data.  This is Mongo’s only guarantee that data is in some sort of resilient state.  Crazy?  I dunno…I’m sorta ok with this approach in that you’d be a fool to have a database on only a single server anyways.  On the other hand, this approach means your master is automatically screwed if it crashes as its data is now unknown, you have to go to a slave and make it master.  This seems like it could be a lot of work, but maybe it’ll just take some getting used to.  Making a slave into a master and having this scenario planned out completely never seems to be fully fleshed out in most organisations with regards to MySQL, so perhaps this will force your hand in it.  They seem to like to force your hand.  Is this by design? Just part of becoming ‘webscale’ and living in a world where the loss of a node (even if it’s master) is standard operating procedure.  Or due to a very new/immature database?  I dunno…tbd.  But in any case, as is the case with the shear nature of a schema-less database, development is really going to have a good understanding of how MongoDB works.

We are going more in-depth into setting up replication tomorrow.  It seems there are a mechanisms specifically in place to be used with ‘snapshotting’ technologies such as in Amazon EBS volumes and NetApp filers (we use the latter extensively), so perhaps this will make having a myriad of slaves available much easier.

Too late to write much more, but to me MongoDB seems much more geared to be a mostly-resilient datastore….maybe a great caching layer?  It’s no replacement for MySQL in many situations where every transaction really really matters.  Developers will have to write their applications knowing this.

hasta

Posted in Uncategorized | Tagged , , , | Leave a comment

Hello world!

Posted on September 24, 2010 by behl@webscaling.com

Really…hello!  Or not..well “Hello world!” in that I can’t tell you how many times I’ve output that in some language/app/webserver/ftp server/etc. etc., or another  (and then not done much else beyond that), and I guess wordpress is my newest, but let’s face it, such is the way of the sysadmin trying to keep up with the wily programmer cats.

Anywho, I’d like to inaugurate my first post with one of the funniest pieces on “web scale” that I’ve seen:

MONGO DB IS WEBSCALE

gawd that’s good, though probably more to me because within the last few weeks I’ve all of a sudden been bombarded with the term “NoSQL” left and right, and learned the term “web scale” is being used…and that I happened to have purchased this domain “webscaling.com” ages ago..apparently I’ve been mentally “web scale” way before anyone else was!  And no sooner than a few days after I heard of and read up on one of the contenders in the NoSQL arena, CouchDB, I learned one of the companies I support was going to go with MongoDB and that I was soon to attend a training class on it.  But of course!  They need “web scale” for their new product!  Strange, since their current product seems to run fine on a MySQL in a master/slave setup with very low CPU.  But who am I to fight the winds, and there may be something to it in certain applications (those being decidedly in the non-financial arena).  I’ve been beat over the head continuously by “cloud computing” too..and as much as I’ve been quick to punish its users as buzz-word compliant cyber hippies, I am beginning to really like the idea of it…more and more so with every support contract renewal I have to sign with Dell, NetApp and Cisco.  Just the time  itself in dealing with all this crap is something to consider. Anyways, more on that later. welcome to the rantings and ramblings of a sysadmin (who is fairly ambivalent about particular distros)/network guy (who believes cisco is still what you want to use in %95 of all situations)

Posted in Uncategorized | Tagged , | Leave a comment