Apr
04

Turris Omnia and openSUSE

About two weeks ago I was on the annual openSUSE Board face to face meeting. It was great and you can read reports of what was going on in there on openSUSE project mailing list. In this post I would like to focus on my other agenda I had while coming to Nuremberg. Nuremberg is among other things SUSE HQ and therefore there is a high concentration of skilled engineers and I wanted to take an advantage of that…

Little bit of my personal history. I recently join Turris team at CZ.NIC, partly because Omnia is so cool and I wanted to help to make it happen. And being long term openSUSE contributor I really wanted to see some way how to help both projects. I discussed it with my bosses at CZ.NIC and got in contact with Andreas Färber who you might know as one of the guys playing with ARMs within openSUSE project. The result was that I got an approval to bring Omnia prototype during the weekend to him and let him play with it.

My point was to give him a head start, so when Omnias will start shipping, there will be already some research done and maybe even howto for openSUSE so you could replace OpenWRT with openSUSE if you wanted. On the other hand, we will also get some preliminary feedback we can still try to incorporate.

Andreas Färber with Omnia

Andreas Färber with Omnia

Why testing whether you can install openSUSE on Omnia? And do you want to do that? As a typical end user probably not. Here are few arguments that speaks against it. OpenWRT is great for routers – it has nice interface and anything you want to do regarding the network setup is really easy to do. You are able to setup even complicated network using simple web UI. Apart from that, by throwing away OpenWRT you would throw away quite some of the perks of Omnia – like parental control or mobile application. You might think that it is worth it to sacrifice those to get full-fledged server OS you are familiar with and where you can install everything in non-stripped down version. Actually, you don’t have to sacrifice anything – OpenWRT in Omnia will support LXC, so you can install your OS of choice inside LXC container and have both – easily manageable router with all the bells and whistles and also virtual server with very little overhead doing complicated stuff. Or even two or three of them. So most probably, you want to keep OpenWRT and install openSUSE or some other Linux distribution inside a container.

But if you still do want to replace OpenWRT, can you? And how difficult would it be? Long story short, the answer is yes. Andreas was able to get openSUSE running on Omnia and even wrote instructions how to do that! One little comment, Turris Omnia is still under heavy development. What Andreas played with was one of the prototypes we have. Software is still being worked on and even hardware is being polished a little bit from time to time. But still, HW will not change drastically and therefor howto probably wouldn’t change as well. It is nice to see that it is possible and quite easy to install your average Linux distribution.

Why is having this option so important given all the arguments I stated against doing so? Because of freedom. I consider it great advantage when buying a piece of hardware knowing that I can do whatever I want with it and I’m not locked in and depending on the vendor with everything. Being able to install openSUSE on Omnia basically proves that Omnia is really open and even in the unlikely situation in which hell freezes over and CZ.NIC will disappear or turn evil, you will still be able to install latest kernel 66.6 and continue to do whatever you want with your router.

This post was originally posted on CZ.NIC blog, re-posted here to make it available on Planet openSUSE.

Apr
03

Shell calendar generator

Some people still use paper calendars. Stuff where you have a picture of the month and all days in the month listed. I have some relatives that do use those. On loosely related topic, I like to travel and I like to take some pictures in foreign lands. So combining both is an obvious idea – to create a calendar where pictures of the month are taken by me. I searched for some ready to use solution but haven’t found anything. So I decided to create my own simple tool. And this post is about creating that tool.

I know time and date stuff is complicated and I wasn’t really looking into learning all the rules regarding date and time and programing them. There had to be a simple way how I can use some of the tools that are already implemented. Obvious option would be to use some of the date manipulation libraries like mktime and write the tool in C. But that that sounded quite heavy weight for such a simple tool. Using Ruby would be an option, but still kinda too much and I’m not fluent rubyist and my python and perl are even rustier. I was also thinking what output format should I use to print it easily. As I was targeting some pretty printed paper LaTeX sounded like a good choice and in theory it could be used to implement the whole thing. I even found somebody who did that, but I didn’t managed to comprehend how it worked, how to modify it or even how to compile it. Turns out my LaTeX is rusty as well.

So I decided to use shell and powerful date command to generate the content. Started with generating LaTeX code as I still want it on paper in the end, right? Trouble is, LaTeX make great papers if you want to look serious and make some serious typography. For calendar on the wall, you probably want to make it fancy and screw typography. I was trying to make it what I wanted, but it was hard. So hard I gave up. And I ended up with the winning combo – shell and html. Html is easy to view and print and CSS supports various of options including different style for screen and print type media.

Html and css made the whole exercise really easy and I have something working now on GitHub in 150 lines of code where half of it is CSS. It’s not perfect, there is plenty of space for optimization, but it is really simple and fast enough. Are you interested? Give it a try and if it doesn’t work well for you, pull requests are welcome 😉

Jan
17

Getting to your PiDrive

ocipv6I wrote few times about my PiDrive already, this is continuation of the work in progress and I would like to share what I did since the last time.

Getting accessible

We need to address two problems regarding the accessibility of PiDrive. First one is actually not that you need to access your PiDrive from Internet, but something much simpler. Once you connect your PiDrive to your local network, you need to find out it’s local address first so you can set it up. There are various options, for example including avahi or netbios and configuring them to publish some recognizable name. I’m sure everybody has those in mind and I do as well. But I wanted to start first with something that might have escaped the others and what I consider quite simple but at the same time quite effective approach. On boot, I display ownCloud logo on HDMI attached display if there is one and bellow it address of the device. My PiDrive came with 90 degrees angle HDMI converter so it looked like it is expected that you will connect display to it. And reading what is written on HDMI is much simpler and reliable than anything you do on computer.

Other accessibility issue is getting to your PiDrive from Internet. I already prepared kinda solution (still need to implement tunnel option thought) for the Internet of tomorrow (IPv6), but as quite some people still live in the past, I extended my application and now it supports even UPnP. What it is and how does it work? If you have smart enough router that allows such kind of thing (most of them, although you probably need to enable it), you can instruct your PiDrive to open up a port on it and forward it to itself. Tricky part is that your router has to support it and you kinda need public IPv4 on the other side (otherwise it misses the point). So it doesn’t solve everything, but gives PiDrive accessible on IPv4 to at least some people. And Dynv6 I implemented previously while playing with IPv6 should be able to resolve to your public IPv4 as well. So you can get ready for the future, while still maintaining compatibility for people living in stone age.

Image

Both of the improvements mentioned above are installed into my image and also finally installed ownCloud on it. Although currently just a git snapshot. For final version, I’ll have to switch to packages I guess, but currently I have some dependency issues with them (and php7) that I need to solve first. You can now try improvements I mentioned by yourself. Just inspect my GitHub repo or you can still download my temporal binaries (now updated).

Jan
10

My way of booting PiDrive (Raspberry Pi2)

PiDrive bootingSome time ago I started playing with PiDrive project. I implemented an application that I think will be useful to people using it in the end – some simple IPv6 enabler/browser and DynDNS client. But I kinda cheated and implemented it on the ARM board I already had at home. Over the last week I didn’t had much free time, but I still continued on the project and I got my Pi booting my custom image. How will PiDrive boot was subject to lengthy discussions on mailing list, so I wanted to provide a proof of concept of how do I think it can be done. As it is long post, TLDR version at the end 😉

Starting points

First, let’s take a look at how Raspberry boots. Most ARM board I encountered so far used u-Boot that was either in internal flash memory or on the SD card at some predefined address. Raspberry searches for a files with predefined names on FAT filesystem that it expects to find on first partition of your SD card. On one hand, it looks weirder, on the other it is simpler if you don’t have any prior experience with ARM. And if you do, you can still put u-Boot there to get all the options u-Boot provides.

Other observation to take into account made by others is that SD cards die quickly in those devices. Mine didn’t yet, but I don’t do any crazy stuff and tend to be lucky. But let’s take for granted that during the life of the device, SD card might die and maybe even multiple times. We should somehow address that. And recovering from broken SD card should be simple so even average Joe can do that.

As I’m openSUSE guy, I obviously picked openSUSE to power my PiDrive, but nothing I did should depend on chosen distribution. I picked 13.2 as Leap for armv7 is not ready yet (about that some other time) and I added few packages that I think can be useful on OBS in separate project.

Last point I have is that I would personally prefer to have system installed on SD card. It will be slower to start, but it will let harddrive to spin down and go to sleep when not used. Prolonging it’s life and reducing the noise of spinning drive. But if system is running from SD card, second paragraph is even more important – we need to gracefully handle SD cards death.

How I boot my Pi

Now you know from what I started and let’s take a look with what I ended up. I wanted to make firsts time installation as easy as possible. As SD cards come preformatted to FAT already, all you have to do to boot is just to copy some files there. I found out what files I need there, tweaked a configuration a little bit and compiled my own kernel. Why? To compile all drivers needed during boot directly in and to include custom initramdisk. For those who don’t know, initramdisk is, as name suggests, small disk in RAM that contains few programs and script that is executed before the system boots and can be used if you need to do some complicated stuff before booting. And that is exactly what I had in mind.

On first boot, my initramdisk takes everything on SD card, copies it to memory (we have 1G of RAM and pretty much nothing is running at this point), then it repartitions the SD card and copies the files back. It makes first partition with FAT smaller and creates new Ext2 partition behind it. What are those for? First partition contains stuff needed by the board to boot up (various firmwares and kernel) but also squashfs compressed rootfs. Once init script will discover correct ext2 partition, it will use it as overlay on top of this squashfs image to make OS image writeable and boots the system using this overlayed filesystem. During boot it also checks whether overlay is on SD is empty (for example because card died) and if so, looks for the backup on harddrive and if found, it is used to populate overlay. So the idea is to use SD card, but backup everything and make a recovery in case SD card dies as easy as possible – you just get a new card from nearest convenience store, unpack an archive on it and boot up. Can’t be simpler I guess.

Little about why choosing squashfs and overlayfs on top of it. SD card is pretty small, and having compressed filesystem will make it much easier to fit. And also, I played with it some time ago and thanks to compressed rootfs device can actually read from it faster as SD cards are slow, but decompression is easy and fast.

If you want to see it or want to try my approach, I put sources to my GitHub repo. It has some implicit dependencies I was too lazy to enumerate and I should write some documentation, but it should download kernel and busybox sources, compile everything, download openSUSE JeOS and Raspberry binary blobs, put everything together and produce SD directory with files to put on SD card. Just for convenience, I will temporally provide binary archive that you can just unpack to SD card and test. Currently it is really just booting. No ownCloud installed yet, although nginx and php7 are there. It should get IP via DHCP, use HDMI out and you should be able to either ssh to it or login on second console using root account and password owncloud.

Plans

What is currently just in TODO is to actually install and play with ownCloud. There is plenty of questions to discuss, like where to put the database and which one. In case of MySQL, we could even divide it and put some tables there and others elsewhere. We have SD, HDD and RAM. Speaking about HDD, also in TODO is to find, format and mount USB drive. That’s also about customizing the final rootfs. Last thing that I would like to do at some point is to try to have an easy way how to recompress the system after updates/additional installs and cleanup the overlay. But that is far future. This post is mainly for people playing with PiDrive to explain which way I’m going and pointing everybody to my GitHub repo :-)

TLDR version

I got my Raspberry Pi 2 booting from SD card and automatically repartitioning it and it’s easy to deploy, just unpack this archive on SD card with FAT. Sources are at my GitHub, so you can take a look at what it does. No ownCloud installed yet. Root password is owncloud.

Dec
31

Getting IPv6 for your ownCloud

As you could have read, I joined the ownClouds PiDrive effort. I like the idea and we were brainstorming on the mailing list regarding what can we do. One notion really popped out. If you have ownCloud at home, you might be interested in reaching your home cloud from anywhere you go. And if you don’t have public IPv4 or you don’t want to forward public ports from the router, you might be interested in getting IPv6 for you home cloud. It can be pretty easy. Both on your home cloud and your notebook. I would like to talk about few options I considered and how and which I decided to integrate them (also into ownCloud app that you can use anywhere).

Overview of options

Native IPv6

You might be lucky and get IPv6 segment directly from your Internet provider. I know mine does offer it. But I also know that quite some providers are trying to fight inevitable future and keep postponing IPv6 deployment. On the other hand, I heard that there are some providers that migrated fully to IPv6 and no longer offer IPv4, just NAT64. If you have native IPv6, you probably know about it and if your router is correctly setup, your home NAS as well as your other computers will get it automatically. So for those lucky ones, my app will just detect IPv6 and display the address you can use to connect to your cloud.

6to4

Kinda nice way to get IPv6, but requires public IPv4 and some advanced setup on the device that has this IP. So probably nothing average Joe will do. But if he does and propagate it to his PiDrive, app will detect it and show it.

Tunnel from IPv6 broker

This is quite popular option. You register with some tunnel broker (like HE or SixXS) and they will give you fixed IPv6 address or range of IPv6 address that you can use however you want. You get always the same IP no matter where you are and setup is usually pretty easy, the only tricky part is registration which often requires you to fill in quite some personal details. I was thinking about providing this as an option on PiDrive, but the need to register somewhere and need to choose a broker sounded quite bothersome, so I decided to support mainly the last option I’m going to mention which I consider the most user-friendly. But as in previous case, if you set this up, the app will detect that IP address that you got this way and display it and this option might be added later on as I consider it quite useful.

Teredo

Teredo is I would say the easiest way (from the end-users point of view) how to get IPv6. You just need to run the client on your machine, and it will figure everything out and assign you some IPv6 address that you can use. It works behind NAT and you don’t have to know anything, it will figure out everything – even the closest relay to use. There are some disadvantages. There is an overhead with figuring out everything, the protocol itself has some overhead and on top of that, your IP depends on public IP of your NAT and how it handles your traffic. It also depends on port you were assigned by your NAT, so your IP will likely change with every reboot. But overall I think it is viable solution for end users if used together with some DynDNS service (where you would need to register but mostly with less personal info). I have in my TODO to add option to support DynDNS as well (started working on it already, but really just started, so nothing published yet).

Conclusion

I think making it easy for home users to enable IPv6 on their home cloud and educating people about how to get IPv6 on their other machines is probably the best way to go regarding how to let people have their data available everywhere they go. An I hope the app I’m working on will help to achieve that.

Older posts «