Wednesday, February 5, 2014

Getting started with Erlang Webmachine on Fedora 20

The problems I am encountering in learning erlang on Fedora 20 is helping me understand erlang better :)

I had to install erlang-ibrowse and erlang-meck even for starting the skeleton application. They should probably be included in the dependencies of erlang-webmachine rpm.

The template for creating the skeleton application is included in

To create a new skeleton app:
$ cd /usr/lib64/erlang/lib/webmachine-1.10.1/priv
$ rebar create template=wmskel prefix= appid=

$ cd
$ rebar compile

The wmskel.template needed to be modified to comment out the following lines related to rebar:
%{file, "{{webmachine}}/rebar", "{{prefix}}/rebar"}.
%{chmod, 8#744, "{{prefix}}/rebar"}.

The version number in rebar.config also needed to be changed from 1.9.* to 1.10.*

However, execution of fails with the error:
 init terminating in do_boot ()

The issue was that in .erl, the following statement fails:

It appears that some of the dependencies of mochiweb are not implicitly started. I am not sure if I am missing something, this is a fedora specific issue or a current mochiweb version issue. A work around was to modify the start function in src/.erl adding the lines in bold:

start() ->

    application:set_env(webmachine, webmachine_logger_module,

For diagnosing, modifying ensure_started function in the same file helped.

ensure_started(App) ->
    case application:start(App) of
        ok ->
        {error, {already_started, App}} ->
        X -> io:format("App failed ~w ~w~n",[App, X])

$ rebar compile
$ ./

http://localhost:8000  should show "Hello, new world".

It may be preferable to modify the start function in templates/src/wmskel.erl.

Thursday, January 16, 2014

Getting started with Erlang Mochiweb on Fedora 20

It is simple to use this tutorial for creating a minimal Erlang Mochiweb application. Clone the git repository and run make twice.

However, trying to do the same on Fedora 20 using the packages erlang-mochiweb and erlang-rebar wasn't so simple.

While the templates are included in the /usr/lib64/erlang/lib/mochiweb-2.4.2/support directory, it is missing the Makefile. We need to execute the rebar commands instead.

Several lines need to be commented in support/templates/mochiwebapp.template. These correspond to files not included in the erlang-mochiweb rpm package -
%%{file, "../../.gitignore", "{{dest}}/.gitignore"}.
%%{file, "../../Makefile", "{{dest}}/Makefile"}.
%%{file, "../../rebar", "{{dest}}/rebar"}.
%%{chmod, 8#755, "{{dest}}/rebar"}.
The script fails. Solution is to replace '\\' by '\'. The script becomes:
exec erl -pa ebin edit deps/*/ebin -boot start_sasl \
    -sname {{appid}}_dev \
    -s {{appid}} \
    -s reloader
$ cd /usr/lib64/erlang/lib/mochiweb- 2.4.2/
$ rebar create template=mochiwebapp dest= appid=
$ cd
$ rebar compile
$ ./

If successful, browsing localhost:8080 shows the success page.

Friday, June 28, 2013

Relying more on Desktop Client for Emails

After switching to Akregator from Google Reader and learning to live with a little inconvenience, I was struck by a comment about the danger of email accounts being broken into by the criminal elements.

I now have setup an imap account and am using Kmail. Contents of any folder/label which need not available for easy access online, I plan to move to a local folder. I will miss out on the power of Google search, but I think, along with consuming less energy, learning to live with some technological inconveniences is the preferred/imperative option.

Update - Came across an interesting news of excessive reliance of technology -  When technology fails a news anchor, there are no words.

Thursday, June 20, 2013

Life after Google Reader - Akregator

Web based services are convenient. It is far too easy to get used to them. I tend to look at my rss feeds from at least two systems. So, it seemed that I will use one of the online services which are trying to replace Google Reader and make the transition as painless as possible.

In view of the recent disclosures about Prism, opting for a little inconvenience is not a bad idea.

I am now quite comfortable with Akregator. One advantage is that I can see and access the entries I have already read as well. The responsiveness is very good.

To switch between machines, I take a tar backup of  .kde/share/apps/akregator from one machine and restore it on the other. Since it is a bit of a nuisance, I am organizing my net activities to normally use one system only for reading rss feeds and switch rarely.

It is not a very serious constraint and probable saves me distractions.

The mail services of our ISP are very unreliable otherwise I might have seriously considered at least partially moving from gmail.

As long as software read the content, I was unaffected; hence, no impact of Microsoft's criticisms of Google. This is probably more common  than just  for me as stories about Eliza illustrate -
Another story tells of the author's secretary using Eliza when he entered the room. The secretary asked her boss to leave until she had finished her conversation.
The author also considered putting in a module that recorded peoples conversations. This was greeted with accusations that Weizenbaum was spying on their secrets and innermost thoughts.
So, humans reading our content is another issue! 

Robots, however, guide and save humanity :)

Inactive logical volume after upgrading to Fedora 19

I upgraded my netbook to Fedora 19 beta version using yum. The process was smooth and went through without a hitch.

The problem came up on rebooting. Systemd waited and finally failed to mount home, which was a logical volume. This seemed strange as root and swap were also on the same volume group and were being used.

Finally, lvscan showed that the home logical volume was inactive. The command
lvchange --activate y 
worked and it was a relief to realize that the home logical partition was perfectly fine.

Unfortunately, rebooting the system showed the same problem. The cause of the problem was that all the lvm2 services were disabled.

Enabling lvm2-monitor.service resolved the issue :)

Friday, April 12, 2013

NFS root unexpectedly squashed

While experimenting with setting up ltsp on Fedora 18, I came across a strange NFS behaviour which took quite some time to iron out.

I was already exporting /opt as a read only file system; however, with root squashed. LTSP added another export for /opt/ltsp with no_root_squash option. 
/opt *(ro,sync,no_subtree_check)
# export for LTSP version 5
/opt/ltsp   *(ro,no_root_squash,async,no_subtree_check)

Everything seemed to be sort of working with a few strange effects, e.g. I could not use passwords and some ltsp scripts were failing.
The problem was that root seemed to be still squashed:
[anil@localhost ~]$ sudo mount amd:/opt/ltsp/x86_64 /mnt
[anil@localhost ~]$ cd /mnt/home
[anil@localhost home]$ ls -l
total 8
drwxrwx--- 2 anil  anil  4096 Apr  6 13:04 anil
drwx------ 2 guest guest 4096 Apr 10 12:35 guest
[anil@localhost home]$ sudo su
[root@localhost home]# cd anil
bash: cd: anil: Permission denied
A workaround was to use fsid=0 although whatever documentation I came across seemed to suggest that it was no longer needed:
/opt/ltsp   *(ro,fsid=0,no_root_squash,sync,no_subtree_check)
Unfortunately, I had forgotten that /opt was also being exported and noticed it only after finding the work-around and getting ltsp to work on Fedora 18.

Sunday, March 31, 2013

Arch Linux installation using ipxe and a Fedora server

Arch Linux is great way to learn, e.g. installing Arch Linux booting over the network. As is usual with Arch Linux, the documentation for the process is excellent. Surprisingly, a mirror in India gave an excellent speed and low latency so even the first stage went well.

Since I was experimenting with ipxe, I decided to install Arch Linux using the iso and ipxe. Using dnsmasq was no problem. However, since I use Fedora and the default is dhcpd, I wanted to make it work with dhcpd. The problem  was finding the equivalent options of dhcp-option-force.

The issue was that the client would try to search for cfg file as per its rules and ignore the specification in the dhcpd configuration file. The solution was available on the syslinux wiki in response to
Can I send information to PXELINUX via special options in the DHCP response?
It is much harder syntax than the dnsmasq's dhcp-option-force but worked.