[caption id=“attachment_10199” align=“alignright” width=“300”] Come join us![/caption]After the recent news, we are now back on stage and with this blog we want to point you to our open positions. Yes, we are hiring people to work on ownCloud. ownCloud is an open source project, yes, but ownCloud GmbH, the company behind the project, provides significant people’s power to expand the project to serve the needs for both the community and ownCloud GmbH’s customers. So if you ever dreamed of getting paid for work on open source, read on.

What we do - what you will work on

The call is for people who understand the vision of bringing the idea ownCloud to an enterprise ready level: ownCloud is not only running on individual open source enthusiasts hardware, but also on sites with huge amounts of data like CERN or the Sciebo project, and at large companies who want to work with their data in a secure way.

To provide the best solution for all of them we are looking for:

A System Administrator

In this role, you make sure that the infrastructure that we use in ownCloud is up and running. That involves troubleshooting and streamlining existing infrastructure, but also designing new services. If you love virtualization of all kinds and have an eye for security, this position is for you. Of course all this does not only happen behind closed doors, but you will be in contact with the open source community around ownCloud.

The Application Security Engineer

For security professionals who would like to take on a high profile open source project. As security is one of the core values of ownCloud, we are looking for somebody who constantly monitors the code flowing in for security problems, is able to find glitches in existing code and handle the bug bounty program. That and more is the task of this high profile position.

A Software Engineer PHP

For engineers with a passion for good software design and a love for writing code without being code monkeys: In this role you iron the server part of our platform, build new features, work on fixing bugs with the support colleagues and bother the architect with new ideas how to make the thing even better. For this you need to urge to get down and dirty with code, feel yourself comfortable in a team of high profile developers who can teach you things and learn from you.

PHP or what?

Yes, ownCloud is written in PHP, and PHP is the most important, but by far not the only language that we use for the ownCloud platform.

Before you turn your back because of PHP, please think twice. There are a lot of good reasons why we are going with PHP, some of them are named in this blog, but there is more: For example PHP7: With PHP 7 (which can be used with ownCloud) the language has caught up with many criticism it faced before and has done a big leap.

And anyway, the language of a system is not the only thing that is important in a developers life. It is rather how many people use, love and recommend the project and the development processes the team lives. And in all that points, ownCloud is already awesome, and will become even more with your help.

Send your resume in to work@owncloud.com so we can get talking!

NAME=sles12sp2b4
IMG=https://example.com/images/SLE_12_SP2_Beta4-x86_64-default.qcow2
wget -O /var/lib/libvirt/images/$NAME $IMG
virt-install --name $NAME \
       --ram 2048 --graphics type=vnc \
       --network bridge=br0 \
       --import \
       --disk bus=virtio,path=/var/lib/libvirt/images/$NAME

I’m often approached by people who wish to translate opensuse-guide.org to their respective languages, which is awesome, but managing translations would be too much work for me. So instead I encourage people to create a derivative work of the guide in their own language – it’s licensed under the GNU Free Documentation License with no invariant sections.

Recently derivatives have been created for Arabic and Spanish by Sadig Osman and victorhck respectively.

Moved to GitHub

I have now made it a whole lot easier for people to fork opensuse-guide.org by putting the guide on github. This also makes it much easier for maintainers of derivative works to keep track of the on-going changes and updates I make to the guide.

The HTML isn’t particularly pretty, and I probably still have some Danish language comments here and there. But please go ahead and fork me.

# Allow to build as root, exceptions per package
# the keys are actually anchored regexes
our $norootexceptions = {
        "my-project/root-package" => 1,
        "dev-projects.*/other-package" => 1,
};

The next OpenStack Summit takes place in Bacelona (Spain) in October (25.-28.10.2016). The "Vote for Presentations" period started on 26.07.2016. All proposals are now up for community votes. The period will end August 8th at 11:59pm PDT (August 9th at 8:59am CEST).

• OpenStack and Ceph @ Converged Microservers - On the Austin Summit the Ceph Community and WDLabs presented about running a 4 Petabyte Ceph cluster on ethernet attached Converged Microserver He8 drives. WDLabs provided access to early production devices for key customers for early adoption and feedback. This talk will provide insight into our experience with running a Ceph cluster on these devices as a storage provider for our OpenStack environment.
• Vanilla or distributions: How do they differentiate? - If it comes to OpenStack there is always the question: vanilla or a distribution. You have the agony of choice, it will highly depend on your usecase and organization. We will take a look behind the curtain of the OpenStack products. What should you know about the offerings? Is there anything you may should evaluate before you choose a solution? There is more to take a look at than only the OpenStack product itself if you include also e.g. KVM and Ceph. What about the base distributions and support?

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