Seems that some cloud vendors (sheesh I really only knew about Google Ape… err App Engine, Amazon’s EC2 service, and GoGrid) have been having some issues watching customer data go up in a poof. oops.
Datacenter Knowledge mentions Flexiscale having issues
The problems for FlexiScale began when one of the main storage volumes was accidentally deleted by an employee during a system upgrade earlier this week.
as well as another company called LinkUp (although I guess it’s down now) having issues too:
a cloud storage previously known as Media Max, which shut down Aug. 8 after losing “an unspecified amount of customer data
Ouch. As the industry fashionistas and the hordes of zombies (and I guess everyone else pulled in from the vortex created) moves towards trying to fulfill what Nicholas Carr dubs the Big Switch I can only surmise that more cases of cloud computing companies will continue to go belly up due to dumb mistakes, poor execution, etc, name your classic dumb mistake here. This will leave behind the vendors who have spent time at multiple levels (besides just technology) to ensure that many of the typical mistakes that will hit any IT business can be recovered from instead of being the critical wound that kils.
Read more!
My short, short suggestion is… don’t: This blog post explains it much better than I can although I definitely have been the victim of trying to generate a GPG key on a headless server to no avail:
While trying to generate a gpg keypair on a remote server, I discovered I lack entropy. Eventually I had to physically type on the keyboard in order to generate enough random bytes.
I guess in the meantime the best workaround is to generate a GPG key on a workstation somewhere and transfer that to the server in question. A little hokey but I guess if you truly need a GPG key that would be my suggestion.
References
Before there was Rails, there existed other Web Frameworks for Ruby. One of the promising ones is Nitro however it fell into realm of ignorance. On some random surfing I ran across this blog post from one of the main authors of the Nitro Web Framework.
It’s an interesting read since the author laments how Nitro could have been a contender but it never took off. The comments are enlightening since it seems there were project (mis)management issues that prevented a community from really forming around Nitro. Anyways, by now, Rails has the lion’s share of the attention so any hopes now would rest on it being so much better that people will switch. My understanding is that it has some things that are better but not such a big enough jump to make people interested, unfortunately.
Read more
Yeesh, I just looked at the date of my first post and it’s been a whole 5 years since I started blogging here.
What have I learned? People who blog multiple times a day must either have some kick-ass tools to do it quickly or way too much time. I seem to have neither so this blog gets infrequently updated.
After looking at a seriously useful tip for cleaning out a clogged postfix queue I puzzled over the -r option in xargs. I’m not an xargs master but I figure if I need it I can always RTFM.
Well man xargs on my Ubuntu box provides the typical GNU fair and I spend the next way too long time period looking for where the -r option is. (The full option is –no-run-if-empty).
Sadly, I ended up finding it faster with a Google search on this web page that has some find-fu and xargs then looking again at the GNU manpage and finally find the option buried just before the EXAMPLES section.
I guess I should be happy this time around, there are some GNU manpages that don’t even HAVE documentation (at least compared to the *BSD brethren). Grrrrrr
After glancing at the Slashdot post on the forking of pidgin and wasting far too much time slogging through the ticket that caused a bit of strife, I’m pretty sure I will move away from Pidgin until the developers stop being dorks (highly unlikely since they seem to develop only for themselves).
Quick quick summary of the whole issue. The pidgin developers decided to make the input text box very small and auto-resizing (up to a certain point) based on some fancy heuristic. Quite a few users have jumped up and down and requested to make this optional however the pidgin developers basically said, ‘Go take a hike’. There has been quite a bit of reaction to it, including the creation of a plugin to bring back old functionality to a full on fork of the whole project.
In general, forks are a bit of wasted effort to the Open Source community as a whole but one will never get the idea situation where all developers will just ‘get along’ and combine their energies into the One True Implementation. So, from a pragmatic standpoint, forking seems to get the job done although with a lot of burnt cycles.
I believe migrating to something like Funpidgin (A fork of Pidgin that aims to be listen more to the community) and making sure that it gets enough momentum to stay alive is probably the best answer to extremely stubborn developers wanting to do things their own way at the expense of the ‘users’. However, I guess we’ll just have to wait and see if the fork gets enough energy to keep itself running.
Had a case where I had some rails app that was using files for its session store and had been running like that for months. While it was a careless (and dumb) thing to run it that way, we had to do something about it since it was eating up close to 85% of the system partition. The dumb way to try to do this is below:
nice find /tmp/ -name 'ruby_sess.*' | xargs -n 100 rm -fv
However, the problem is that this causes insanity on IO which is NOT good for a running service. (Luckily this service was merely important instead of critical) So, I present to you my quick and dirty script that will clean up all those nefarious ruby sessions files that have run amok for months.
while true; do
nice find /tmp/ -name 'ruby_sess.*' | head -n 20 | xargs rm -fv; sleep 10
done
After a long time of not updating my trusty old iLamp iMac, I finally updated it to 10.4.11 over the weekend and let it lie. Later on I hear a report that Safari won’t start up.
That’s odd, I’ve never heard of Safari having launch problems before. I check the log and I see something like the following:
Date/Time: 2008-04-14 22:06:45.474 +0900
OS Version: 10.4.11 (Build 8S165)
Report Version: 4
Command: Safari
Path: /Applications/Safari.app/Contents/MacOS/Safari
Parent: WindowServer [86]
Version: 3.1 (4525.13)
PID: 20987
Thread: Unknown
Link (dyld) error:
Symbol not found: _WebDatabaseDirectoryDefaultsKey
Referenced from: /Applications/Safari.app/Contents/MacOS/Safari
Expected in: /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit
Those type of messages go on and on in Console.app. My first round of Googling brought me to a Macrumors thread that recommended deleting the history.plist and other parts from ~/Library/Safari. I tried removing various files from that directory to no effect and finally just removing the directory altogether. Nada.
Troubleshooting a PC WITHOUT a web browser really sucks. I suggest everyone try it once in awhile to see just how much the nature of debugging IT problems has changed when you are deprived of a very powerful tool. Luckily, this Mac had a very crufty version of IE lurking so the first thing I tried was a download of Firefox. However, the disk image refused to be mounted! Seems this is also tied in with the security update. So basically, I’m left with using IE as my main tool for debugging on this Mac.
After a bit of googling, it seems that the fix is tied requiring the latest OS X security update (Available at the Support Download page). For OS X 10.4.x users you can find a link to the latest Universal here.
However, there is a catch. The security update is only available from that page as a Disk Image. Guess what you can’t open it up under the affected Mac. At this point you’re left with 2 options:
- Burn the Disk Image to a CD-R/DVD-R and use it that way
- Transfer the disk image to another Mac and unarchive it then push it back
I decided on the latter option since I hate wasting a CD-R if I don’t have to. After applying the Security Update and rebooting, Safari boots up and things seem chipper again but that was a serious side trip on something I’ve rarely seen Apple ever mess up. Anti-kudos to Apple for making this update on your ‘legacy’ OS really sucky.
Anytime I’ve been running a perl based script on my leopard box I got this really irritating output with whatever else I was expecting:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = "En_US",
LANG = (unset)
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
With a quick Google search I found an answer in this Rubify post. Basically the solution / fix is to make sure the following is set in either your ~/.profile or ~/.bashrc or ~/.cshrc
# This setting is for the new UTF-8 terminal support
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
Read more at Rubify!
Virishi tells a story of Meraki (an off-shoot of MIT Roof-Net) changing their tune.
Today I learn that my failure is due to the fact that Meraki has automatically updated the software on all of the units (including legacy, such as ours) so that you cannot install a different firmware on it, at all.
Not cool
Read more
I’m dumb. I had a bug in a checker script that I wrote and only noticed it recently when I bothered to RTFM. Can you spot the error? Probably most programmers will.
Non-working version
require "luasql.mysql"
env = luasql.mysql()
mysqlconn = env:connect("somedb", "someuser")
curs = mysqlconn:execute("
SELECT COUNT(*) FROM some_table WHERE col1 = ''foo")
print("Number of rows in $dlq queue is: ", curs:numrows())
Working version
require "luasql.mysql"
env = luasql.mysql()
mysqlconn = env:connect("somedb", "someuser")
curs = mysqlconn:execute("
SELECT COUNT(*) FROM some_table WHERE col1 = ''foo")
print("Number of rows in $dlq queue is: ", curs:fetch())
Luckily this forum post explains the issue.
I’ve had this problem if the munin-update process takes longer than 5
minutes. The reason this happens is because the cronjob is set to run
every 5 minutes to gather data, so if it is still running from the last
job, you will get this error.
Read it yourself
While going through my blog feeds I came across a post on Ubuntu Geek on lighttpd with php5 and mysql support. One choice quote from the article sort of irked me as I was scanning through it:
With a small memory footprint compared to other web-servers, effective management of the cpu-load, and advanced feature set (FastCGI, SCGI, Auth, Output-Compression, URL-Rewriting and many more) lighttpd is the perfect solution for every server that is suffering load problems.
While I can agree with the author’s assessments on lighttpd serving static files, I’m still not 100% convinced it is the end-all be all solution once you throw in FastCGI + PHP5 in the backend. In general, it’s a no-brainer that you should not be using Apache if you need performance AND are serving static files. You are far better served by using nginx or lighttpd or probably any of the new generation of lighter-weight web servers out there.
However, the game changes when you toss in backend FastCGI processes and MOST of the handling of the website is dynamic content generation by the PHP backend without that many static files. Why do I say this? I’ve converted over an Apache 2 setup with mod_php5 to lighttpd with FastCGI and have been monitoring it stats for awhile and a few things that sort of surprised me was:
- CPU usage hasn’t changed that much
- The memory consumption systemwise also doesn’t seem to be that much different
- Load averages overall seem a little bit higher
However, there are probably many flaws with my observations since this is a live running system that I’m very loathe to apply scientific measurement since this could easily produce downtime on a system I’d rather not take down. Overall, I have been a little disappointed that switching to lighttpd + fastcgi hasn’t really done much to drop the system resources as much as I hoped.
My guess right now is that since a lot of the work has to be handled by the FastCGI backends which is PHP, switching to lighttpd hasn’t really been that much of a gain since in the end most of the handling on that server is being done by PHP with lighttpd merely fronting it so lighttpd might be light indeed but the FastCGI PHP processes aren’t. I guess this goes to show you that one should not always dogmatically believe the hype.
The Industry Standard comments on Why don’t we accept less than 99.999% to which I say… are you willing to really pay for it?
For many things, I’m not. Demanding without paying is basically asking for a freebie. This smells of rant without a basis in my book.
Recent Comments