Skip to main content

OpenBSD 5.0 + Mojolicious + Redis + Beanstalkd

[update 2011-11-06] Recently I installed Mojolicious 2.22 without a hiccup.  Tonight I tried to install the latest 2.24 release.  The challenge tonight was that I needed to upgrade Test::Pod and Test::Pod::Coverage. I just guessed which modules were old based on the output from the build, however, it was 90% luck and 10% intuition. While I hate deep dependencies I wish they would have said something about this before leaving me to fend for myself. This is the sort of thing that make admin/DevOps work dangerous.

[update 2011-11-04] I'm trying to run my test program and I'm finding errors with module dependencies. I'm making the corrections inside the doc.  CRAP! One more thing I found. This time it was my fault. One of the Mojo guys asked me to check the clock/Timezone.  I thought I had. Crap!  I missed it. The clock was wrong and in fact it was 4 days behind. Since the Mojo files were technically 4 days in the future they would not build properly.  When I re-installed NTPD and corrected the clock... Miraculously it installed from CPAN.

[update 2011.11.03] looks like I managed to get everything to install. It's not totally painless but it's also not as involved as making code changes.

I really like OpenBSD (OBSD) and I've used it for years. The only comparison to other OS' that I want to make is that while these guys are pushing development forward with new ideas they truly embrace the "Unix" way by making use that "the sum of the parts is bigger than the whole". What I mean by that is that they build larger applications by incorporating specialized smaller ones. They are also more interested in security and correctness rather than security by constant change or obscurity.

Enough of that.

Armed with a current version of OBSD 5.0 installed in a working VMware instance... I wanted to install The tools I'd need for my next application idea. (skynet-pl). The installation of the primary framework tools was really simple.

Install redis and beanstalk proper (you'll need some basic packages from the CD; not listed here)
cd /tmp
wget https://github.com/downloads/kr/beanstalkd/beanstalkd-1.4.6.tar.gz
tar zxvf beanstalkd-1.4.6.tar.gz
./configure
gmake
gmake install

pkg_add http://ftp.openbsd.org/pub/OpenBSD/5.0/packages/i386/redis-2.2.12.tgz
cd /tmp
wget http://redis.googlecode.com/files/redis-2.2.15.tar.gz
tar zxvf redis-2.2.15.tar.gz
cd redis-2.2.15
gmake
gmake install

(gmake test; is recommended, however, you need to install TCL first)

pkg_add http://ftp.openbsd.org/pub/OpenBSD/5.0/packages/i386/p5-Mojolicious-1.16.tgz
cd /tmp wget http://cpan.metacpan.org/authors/id/S/SR/SRI/Mojolicious-2.22.tar.gz tar zxvf Mojolicious-2.22.tar.gz cd Mojolicious-2.22 /usr/bin/perl Makefile.PL touch Makefile.PL Makefile gmake gmake install

Install the libs from the CPAN (cpan and redis should be running in the background before you try to install the packages.)
curl -L http://cpanmin.us | perl - --sudo App::cpanminus
sudo -s 'cpanm Test::Pod'
sudo -s 'cpanm Test::Pod::Coverage'
sudo -s 'cpanm Mojolicious'
sudo -s 'cpanm AnyEvent::Redis'
sudo -s 'cpanm AnyEvent::Beanstalk'
sudo -s 'cpanm EV'
sudo -s 'cpanm JSON'

Well, that installs everything, however, it is not current.  Redis and Mojolicious are still back level. I hope to resolve this shortly.

PS: I tried to force Mojolicious 2.22 to be installed with the ports collection. FAIL. I also tried to install the latest redis too.  FAIL. I suppose I should try "OpenBSD 5.0 + TornadoWeb + Redis + Beanstalkd" next, however, initial tests are not looking good.

Comments

  1. Installing Mojolicious from CPAN is trivial as it has no deps besides the perl core.

    ReplyDelete
  2. Yes, I agree, however, the make file fails... on OpenBSD.

    ReplyDelete
  3. I started digging a little deeper. I installed GMAKE and tried again. Here is the output:


    # gmake
    gmake: Warning: File `Makefile.PL' has modification time 272524 s in the future
    Makefile out-of-date with respect to Makefile.PL
    Cleaning current config before rebuilding Makefile...
    make -f Makefile.old clean > /dev/null 2>&1
    /usr/bin/perl Makefile.PL
    Checking if your kit is complete...
    Looks good
    Writing Makefile for Mojolicious
    ==> Your Makefile has been rebuilt. Please rerun the make command. <==
    false
    gmake: *** [Makefile] Error 1


    You'll notice that the primary complaint is that the date assigned to the Makefile.PL is so far in the future. This might be ok on some systems... it did not work on OpenBSD 5.0. When I tweaked the dates of Makefile/PL and Makefile(after running perl Makefile.PL)... it seemed to build and install properly.

    PS: this is far from getting CPAN to install the program.

    ReplyDelete
  4. by default:


    # date
    Sun Oct 30 06:14:56 EDT 2011

    # ls -l /etc/localtime
    lrwxr-xr-x 1 root wheel 30 Oct 29 19:34 localtime -> /usr/share/zoneinfo/US/Eastern

    ReplyDelete
  5. I'm not sure what I was looking at when I posted my TZ and system time. The clocks were off. and I was totally missed that. Thanks for the reply. I should have seen it. CPANM installs Mojo nicely on OpenBSD 5.0.

    ReplyDelete

Post a Comment

Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: http://www.eeti.com.tw/drivers_Linux.html (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the setup.sh answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).

TL;DR;

I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…