Recently we implemented Tally ERP 9 solution for Antico Pumps. That itself is not interesting, the interesting part is they are using LTSP Fat client system on openSUSE. They have only one server from which all their client computers boot over the network, the clients do not have hard disk, client OS with all softwares they need including wine(Tally is Windows only software), as well as users’ data resides on the server. Once the client boots all the local resources are used so single low power server can be used to serve many clients.

Tally multiuser is served from a Samba share  on a NAS device, Tally folder is copied to samba share and path to Tally Data is changed so that it points there. Everything they need including printing and export(CSV) works from all clients. Same way Tally can be run on standalone computers. Neither Tally, Wine or openSUSE are modified for getting it working as it would under Windows environment.

Intex Aqua Fish

A few days ago the Intex Aqua Fish became publicly available. This is the first 3rd party phone officially running SailfishOS from Jolla.

Unfortunately the phone is only for sale in India currently, for the price of 5.499 rupees (roughly 80 (eighty) USD!). If you are in India you can get it from one of these outlets:

• http://www.ebay.in/itm/Intex-Aqua-FISH-with-Qual-Comm-Snapdragon-4G-2GB-RAM-16GB-ROM-8-0-2-0-/142056036614
• http://www.ebay.in/itm/Intex-Aqua-Fish-4G-LTE-with-Qualcomm-Snapdragon-5-2GB-RAM-16-GB-8MP-/282098603976
• http://www.amazon.in/Intex-Aqua-Fish-Orange/dp/B01IHFLXB4/ref=sr_1_1?s=electronics&ie=UTF8&qid=1469012735

I’m told that build quality and camera are pretty decent, especially considering the price. The performance is very good, as you would expect, SailfishOS 2.0 is running very smooth even on the Jolla Phone which has much lower specs than the Intex Aqua Fish.

SailfishOS

SailfishOS stands out because of:

• Very elegant and efficient swipe based UI great for one-handed use
• Long battery life
• The Android runtime letting you run most Anodroid apps
• Real multitasking
• Proper GNU/Linux system underneath including use of SUSE technologies like libzypp, zypper and Open Build Service.
• It’s based in Finland and started by ex-Nokia people.

Other options

Recently Jolla sold a few hundred identical phones aimed at the developer community, but they sold out in a matter of hours. So for the time being the rest of us not in India, are left jealously waiting for the Turing Phone to become widely available or for Fairphone to officially offer Sailfish as an option. Or hoping for Intex to start offering the phone globally, or for some other entrepreneurial people to start exporting it.

After upgrading my home NAS server, reinstalling FreeBSD and changing a bit the configuration of my services running on this machine, I wanted to reconfigure my notification system to receive periodic emails about the status of zfs, security, and so on. So, here is just a quick tutorial how to configure smartd, zfs-periodic (to take zfs snapshots hourly/daily/...) and OpenSMTPD to forward all the emails which are sent to the local "root" account to my gmail email address.

• FreeBSD 10.3

# uname -a
FreeBSD nas.home 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 02:10:02 UTC 2016     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

• install Smartmontools package

# pkg install smartmontools

• enable it at boot time (you can also use sysrc command to edit your rc.conf file)

# echo 'smartd_enable="YES"' >> /etc/rc.conf

• we need to create the config file

# cp /usr/local/etc/smartd.conf.sample /usr/local/etc/smartd.conf

• and activate the daily check (you can find your devices using dmesg)

# echo 'daily_status_smart_devices="/dev/ada0 /dev/ada1 /dev/ada2 /dev/ada3 /dev/ada4”' >> /etc/periodic.conf

ZFS snapshot automation tools

There are different packages which can work for you, for example: sysutils/zfs-snapshot-mgmt, sysutils/zfsnap, sysutils/zfstools. But I am using since 2009 sysutils/zfs-periodic and was working really nice for me so I don't see any point to change it.

• install the package

# pkg install zfs-periodic

• add to /etc/periodic.conf

hourly_output="root"
hourly_show_success="NO"
hourly_show_info="YES"
hourly_show_badconfig="NO"
hourly_zfs_snapshot_enable="YES"
hourly_zfs_snapshot_pools="YOUR-POOL-NAME"
hourly_zfs_snapshot_keep=4
daily_zfs_snapshot_enable="YES"
daily_zfs_snapshot_pools="YOUR-POOL-NAME"
daily_zfs_snapshot_keep=7
weekly_zfs_snapshot_enable="YES"
weekly_zfs_snapshot_pools="YOUR-POOL-NAME"
weekly_zfs_snapshot_keep=5
monthly_zfs_snapshot_enable="YES"
monthly_zfs_snapshot_pools="YOUR-POOL-NAME"
monthly_zfs_snapshot_keep=2

This configuration should be enough and should work, is really simple, but here are some additional things I added to my /etc/periodic.conf file (for next entries you don't need zfs-periodic to be installed, they are part of FreeBSD):

# check ZFS
daily_status_zfs_enable="YES"
# list ZFS pools
daily_status_zfs_zpool_list_enable="YES"
# enable daily ZFS scrub
daily_scrub_zfs_enable="YES"
# empty string selects all pools
daily_scrub_zfs_pools="POOL1 POOL2"
# days between scrubs
daily_scrub_zfs_default_threshold=“7"
# check ports for security issues
daily_status_security_portaudit_enable="YES"

There are many useful things which you can add, for more check /etc/default/periodic.conf file.

Now, all these notifications from periodic will be emailed to the local root account. I prefer to have them forwarded to my gmail account. So here is how I did it. I used OpenSMTPD which is an implementation of the server-side SMTP protocol. Yes, Sendmail is coming as default with FreeBSD but I disabled it. I used it for many years, some years ago, but these days I prefer to work with Postfix.

• first we need to stop the sendmail service which is running by default

# service sendmail stop
Stopping sendmail.
Waiting for PIDS: 741.
sendmail_submit not running? (check /var/run/sendmail.pid).
Stopping sendmail_msp_queue.
Waiting for PIDS: 744.

• and disable sendmail at boot (we don't want it to run again after a restart). Add to your /etc/rc.conf

# Disable Sendmail MTA
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

• let's install the OpenSMTPD package

# pkg install opensmtpd
New packages to be INSTALLED:
    opensmtpd: 5.9.2p1_1,1

    [...SKIP...]

    If you are upgrading from OpenSMTPD version 5.7.3 or earlier, please
    follow the procedure below to update the permissions on the OpenSMTPD
    spool directories:

      1. Stop 'smtpd' service:

         # /usr/local/sbin/smtpctl stop

      2. Update permissions:

         # chown -R _smtpq:wheel /var/spool/smtpd/corrupt
         # chown -R root:_smtpq /var/spool/smtpd/offline
         # chown -R _smtpq:wheel /var/spool/smtpd/purge
         # chown -R _smtpq:wheel /var/spool/smtpd/queue
         # chown -R _smtpq:wheel /var/spool/smtpd/temporary
         # chmod -R 770 /var/spool/smtpd/offline
         # chmod -R 700 /var/spool/smtpd/purge

      3. Start 'smtpd' service:

         # service smtpd start

We don’t upgrade a previous installed version so we can just ignore the above message

• enable it at boot (add to /etc/rc.conf)

# OpenSMTPD
smtpd_enable="YES"

Let’s try to configure OpenSMTPD.

# cp /etc/mail/aliases /usr/local/etc/mail/aliases

• uncomment the root line in /usr/local/etc/mail/aliases to have it like this

# Pretty much everything else in this file points to "root", so
# you would do well in either reading root's mailbox or forwarding
# root's email from here.

 root:  GMAIL-USERNAME@gmail.com

• create a "secrets" file in /usr/local/etc/mail/ with the content

credentials GMAIL-USERNAME:GMAIL-PASSWORD

• now we have to generate the aliases and secrets db to be used in opensmtpd config file:

# cd /usr/local/etc/mail/
# /usr/local/libexec/opensmtpd/makemap aliases
# /usr/local/libexec/opensmtpd/makemap secrets

• let’s see if the db files were created:

# pwd
/usr/local/etc/mail
# ls -ltr *.db
-rw-r--r--  1 root  wheel  131072 Jul 16 19:36 secrets.db
-rw-r--r--  1 root  wheel  131072 Jul 16 19:37 aliases.db

• now we need a config file for opensmtpd /usr/local/etc/mail/smtpd.conf. Here is the content

listen on 127.0.0.1

table aliases db:/usr/local/etc/mail/aliases.db
table secrets db:/usr/local/etc/mail/secrets.db

accept for local alias <aliases> deliver to mbox

accept for any relay via tls+auth://credentials@smtp.gmail.com:587 auth <secrets> as GMAIL-USER@gmail.com

• let’s start once OpenSMTPD (we already added it to /etc/rc.conf to start automatically after restart)

# service smtpd start
Performing sanity check on smtpd configuration:
configuration OK
Starting smtpd.

• check to see if the service is listening to port 25

# netstat -an | grep LIST
tcp4       0      0 127.0.0.1.25           *.*                    LISTEN
tcp6       0      0 ::1.25                 *.*                    LISTEN

• now, let’s send a test email to local root account to see if it will be forwarded to my gmail email address: GMAIL-USER@gmail.com

# echo "This is a test" | mail -s "Testing OpenSTPD" root

• if we check the log files, we will see that the email was sent, indeed

# tail -f /var/log/maillog
Jul 16 19:41:21 nas smtpd[78403]: smtp-in: Closing session 67c64e075759c7af
Jul 16 19:41:21 nas smtpd[78403]: smtp-out: Connecting to tls://74.125.136.xxx:587 (ea-in-f109.1exxx.net) on session 67c64e105d261179...
Jul 16 19:41:21 nas smtpd[78403]: smtp-out: Connected on session 67c64e105d261179
Jul 16 19:41:22 nas smtpd[78403]: smtp-out: Started TLS on session 67c64e105d261179: version=TLSv1.2, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128
Jul 16 19:41:22 nas smtpd[78403]: smtp-out: Server certificate verification succeeded on session 67c64e105d261179
Jul 16 19:41:23 nas smtpd[78403]: relay: Ok for d7ace5ca896de069: session=67c64e105d261179, from=<GMAIL-USER@gmail.com>, to=<GMAIL-USER@gmail.com>, rcpt=<root@nas.home>, source=192.168.0.20, relay=74.125.136.109 (ea-in-f109.1exxx.net), delay=2s, stat=250 2.0.0 OK 1468698419 z5sm4117476wme.5 - gsmtp
Jul 16 19:41:33 nas smtpd[78403]: smtp-out: Closing session 67c64e105d261179: 1 message sent.

It seems that everything is working, so we are done!!!

I made Geeko biscuits with the biscuits cutter 3D printed I was given the last day of the openSUSE conference.

Here there are the biscuits before cooking then:

And the final result:

I have to say that as the cutter has such a complex shape it is quite difficult to use, but the biscuits are so cute that it is worthwhile!! I’ll try with a different recipe next time, maybe it will get easier

Polyglot project aims to provide the summary of various choices available for each of the components while developing a web application. It details their strengths so that one can easily choose the right component to build a great solution.

I had gone through several blogs, stack-overflow/quora answers to choose a proper database, programming language, web-framework etc. to build a solution in the past. Most of them were out-dated and I had to keep track of the date for each of the posts.

So for this HACKFEST 2016, wondered how would it be if we could share the learning through a wiki and collaboratively maintain an up-to-date content. I had a hunch that this might be a problem that many would have faced and would be good to solve.

It starts with Questions/Concerns one should keep in mind before starting a project. It goes deep enough, providing a Syntax Cheat Sheet so that one can use it to directly shift the mind from one language to another by going through a single page. It also lists various WebFrameWorks and several Programming Language choices. Am a big fan of Rails and GoLang. The idea is a work in progress..

The wiki is available on github!! It would be nice to collaborate and make it better

Maintenance and security updates for the stable openSUSE Leap releases are automatically tested using OpenQA, and also receive community testing prior to release. In addition, many updates to openSUSE Leap are inherited from SUSE’s enterprise products, where they already receive thorough review, and automated as well as manual testing.

Should anything go wrong, here is how to “uninstall” an online update using zypper.

zypper in --oldpackage ` \
zypper info -t patch --conflicts openSUSE-2016-XXX | \
grep " < " | while read NAME C VERSION; do \
rpm --quiet -q --queryformat "%{name}\n" $NAME && echo "${NAME}<${VERSION}"; \
done`

Replace openSUSE-2016-XXX with the update in question. All involved packages are installed in a prior version. This, of course, is an alternative to using Btrfs snapshots. Note that the update will be offered again.

If you want to help review proposed online updates, just check the “untested updates” repo in YaST or add one of the -test repositories to receive updates early.

dd if=/dev/zero of=wxp.img bs=1M seek=10240 count=0
fdisk -c=dos wxp.img # resize partition, activate(!)
losetup -Pf wxp.img
ntfsresize /dev/loop0p1
losetup -d /dev/loop0

So Hackweek 14 is over. It started during the openSUSE Conference 2016 on Friday June 24 and continued all over the following week.

I had worked on integrating snapshots with Salt with Pablo just some weeks before that and I was waiting for the openSUSE Conference to get the chance to show Thomas what we had done in order to get feedback and figure out next steps.

A few days before the Conference Redhat did a press release that caught my attention: a framework to build container images with Ansible. Yes, that makes a lot of sense. My head started immediately to think all day long about the challenges to build something like that: Installing the configuration management tool without leaving it there, etc. I got curious and started poking at the README.

On one hand, it was not what I was expecting (well, at least, for a Press Release or Tech Preview). It still “generated” Dockerfiles, relied on Ansible to be installed in some way, wich was “templated” into Dockerfiles, and it was of course a new tool.

On the other hand, it was pure inspiration: I remembered why I like Salt so much. I knew that with Salt I wouldn’t need to build a “new tool”. I’d only need to write a module and connect some pieces, and that makes my feature distributed, accessible, deployable, etc. I’d not need to interact with Docker directly, but only with the Salt execution module for it. The best part: I had a Hackweek project!.

I used the chance that Thomas was at the openSUSE Conference to ask him some details about salt-thin and explain him rough ideas.

The feature went more or less like expected:

• A Docker image is basically another image, modified.
• The problem can be reduced to run a Salt state run inside of the container, modulo problems.
  • The image does not have Salt.
  • After the State run, we can’t leave Salt there.
  • The container does not have connectivity with the Salt master.
  • Pillars may be templated against grains which come from the container.

After tackling the problems one by one, you can factor some stuff out:

• If dockerng.build_sls needs to apply state on a new container and commit it, why not allow to call state on a running container?. dockerng.sls was born.
• If we are going to call state.sls and grains.items on the container, why not allow to call any module in a container?. dockerng.call was born.

On Friday I was able to give the following Lightning Talk:

The result is:

• You can build images using your own salt:// tree modules only needing Python on the base image. And yes, you can consume pillar data.
• You can execute modules on containers. Which will be interesting to see how it can be used for auditing (eg. HubbleStack).

I prepared a pull request, which had the best reception I ever got on a pull request:

There are some details to polish and I hope it can be merged soon.

After writing a lot about the openSUSE Conference 2016, it is time to write about how my GSoC project is going.

What I have done

As I explained in my first post, my project main objective is to improve the schedule. So, in this first part I focused on the public schedule, which includes the schedule itself and the all events section.

Schedule

Before explaining what I did, I’ll show you how the schedule used to be:

Well, maybe you think that it was not that bad, but look what happened in a mobile phone:

And this is how it looks now in the mobile phone:

And for tablets and big screens:

I think that the changes are really apparent. We decided to turn the schedule, having the times at the top, to use the space more efficiently. We looked for a mobile friendly solution for the schedule. At the beginning I wanted to use horizontal scroll, but my mentor made me realise that it is not very common and consequently most people wouldn’t understand it. So at the end I used a bootstrap carousel in which the interval of time that appear in every item of it is smaller when smaller is the device screen. I think that this is probably the only responsible option for a schedule, apart from using horizontal scroll, and it works pretty well. I also changed the tabs by a selector that fits all screen sizes and that is also better when the conference is too long.

The schedule height is at least 600px, as more devices are higher or equal to 600px, so that way we use most of the space. It was also important that every row and column had the same size. Regarding rows, it was very disconcerting that the carousel changed its size when clicking next. To keep all the rows with the same height I had to short the text. At the beginning I tried to do it truncating the title after a fixed number of characters, but I didn’t like that I wasted a lot of space, sometimes the title was too short or there was a lot of free space. At the end I used css to limit the title to a number of columns that depends on the the available height. In the case of columns, the fact that every time cell had a different size was what I hated the most of the old schedule. It was confusing, short events with a long title had more space than longer ones with a shorter title. Now the size of an event gives to a cue of how long it is, and I think that this is one of the main purposes of an schedule. The picture of the speaker is also dynamically adapted to the free space that there is left after adapting the number of lines and the cells height.

All events section

I also changed the all events section of the public schedule, although the pull request is still open: https://github.com/openSUSE/osem/pull/1032 But I think that we will be able to merge it next week. It used to be just an unordered list with all confirmed events:

Now, the events are ordered by date and time and it is also included at the end a section of confirmed events which are not yet scheduled . The event boxes also include other useful information such as the start and end time, the room, the track and the speaker picture. I think it looks really nice:

As you can see, I also added a selector with the dates at the top in which dates with no events are in grey to indicate it, so that way we provide an overview of the dates of the conference and reaching a concrete date is much faster. I’ve also added a button to go up in every date to make it easier to go up when there are many events.

Open the schedule in the current date

Another important feature, which I am pretty sure that people attending a conference will thank, is that the schedule is open in the current day and time. I think that this is very important taking into account that we are using a carousel and that in the mobile phone, which is the device that more likely people use when attending a conference to check the schedule, only one hour is rendered per carousel item. That means that otherwise we would have to click next repeatedly to reach the current time, specially when the day is almost finishing. Also, the all events section is open in the current day. Here it is not that important to go to the current time, as you just have to do scroll to find it and I implemented it and the code is quite complex.

Taking background colour into account

The track label used the track color for the background. It was always used white text for the name of the track and for some colors that made the name difficult or impossible to read. Now, the text is black or white depending on what of them provides a better readability. You can see the difference in the following images, where the text is the hexadecimal color of the background.

Style

I have hamlfy all views related to the schedule that were not already written in haml.

I also moved the all events view to a different controller method as that view was getting too complicated due to being together with the schedule.

What I have learned so far and things I liked

I have decided to put together the things I liked with the things I’ve learnt because what I like the most is that I am learning a lot of things. One of the best things of working at openSUSE is that I have the chance to work with a lot of intelligent people that come up with amazing ideas. That’s why I like the correction that my mentors and other people working on OSEM make me, it is the best way to learn. I also like that my mentors always help me when I have doubts, sending me links to useful information so that I can find a solution. Another thing I really appreciate is that I can always give my opinion and that everybody opinion is taken into account to decide the final design or implementation. And because of that I also loved all the things I’ve done, and to be honest now that I am putting all the screenshots together for the post I like them even more

Regarding the things I’ve learned, the part where I feel I have improved more is on the use of git. When I started working on OSEM I spent more time fighting with git than working on the project, and I feel quite comfortable using it now. It was also the first time I used Rubocop and at the beginning I didn’t understand why it didn’t like any code I wrote. But I’ve got used to it, I’ve also installed a Rubocop plugin for atom and now I like that it corrects my style mistakes. Tests were also new for me. I’ve already added or fixed few test but I think there are still things I have to learn and I think I’ll have the chance to do so in the last part of GSoC. I hadn’t used haml before neither and although learning it was easy I didn’t like as I much as I like it now at the beginning. Installing an atom plugin that colors haml made the difference, it is much easy to read it if it is colored.

And of course I’ve also learnt many things regarding Ruby on Rails too. The first one I remember is that I found out that count, length and size methods don’t do the same thing. Regarding Bootstrap, I’ve learnt a lot of things too, such as what panels are.

Challenges I experienced

When working on the schedule I found a little bit frustrating that we spent a lot of time trying to decide what the best design was, so I felt I was going much slowlier than I had expected and I sometimes worked on things that at the end we decided that we didn’t like. Although seeing how wonderful the schedule looks like I am pretty sure that it was worthwhile.

Sometimes I feel a little bit disappointed when I have to throw away something in which I’ve spent a lot of time, but that remembers to what my drawing teacher told me when I was leaning painting:

If you really want to learn painting your objective can not be to decor your house with your paintings. You can not fall in love with your drawings, they are just exercises so you have to throw them away and when you learn then you will be able to decor your house.

So, that is the same, when I throw something away I keep what I learnt and at the end the final result is much better But it is still hard throwing things haha.

What’s next?

Currently I am working on allowing to have multiples schedules in the backend before deciding which of them to use. For that I’ve already introduce new models and associations. The following schema illustrate it (it is not a schema I did for the blog, I like to look at it when working on that, it helps me not to get lost with the relations):

There are still many things to do before finishing it. Probably the most challenging will be merging it, as there are few pull request quite big that interfere a little bit. I’ll try to separate features in different branches if it is possible with the objective of having less files to look at the same time when merging.

The next thing I am going to start with is the admin interface for the schedule backend: integrate it and make it more usable. I am going to show you how it looks like now, so you will be anxious to see my post with the changes haha.

To finish the post I would like to thank my mentors the time they spend reviewing my work, giving me support and solving my doubts.