Today is a special day for Nextcloud and me because Nextcloud gets a cool and important new capability. This is end to end encryption for file sync and share. Nextcloud supports server side encryption for a long time and all file transfer over the internet is encrypted with

TLS/SSL of course. But there is still the need for full end to end encryption to make sure that the data is secure in all scenarios. One

example is that the current server side encryption doesn’t protect the data against an evil server admin or if the server is hacked. The new end to end solution does that.

This feature is more important then ever in the light of Trump and other governments including western ones like the UK who want to have access to the private data of users.

Please read this blog post about the upcoming dangers in the next few months. European datacenter is no solution, recent developments show

Most requested feature

End to end encryption is our most ever requested feature. Users and customers have been asking for this for many many years so I am super happy that we finally do this now. So you might ask “what took you so long?” There are many reasons.

The first is that it is hard. This needs to be done without compromising the user experience. Then we wanted to support as many core Nextcloud features as possible, for example sharing. And we wanted to do this in a way that doesn’t compromise performance. Obviously security is the highest priority and that is hard in itself. But another must have requirement is to make the feature truly enterprise ready. So real key management is necessary and it has to be designed with the assumption that users make mistakes. We don’t need another solution that is aimed at technical users, losing their data when they forget their password for example… Our solution doesn’t even let users pick their own password, taking away the risk of passwords that are easy to hack due to reuse or shortness! We also wanted to implement this feature fully transparent and native in all clients and fully open source instead of integrating a third party tool. It was hard to find a solution that balanced all these requirements. But I’m happy to say that Björn, who already designed and developed the server side architecture and Lukas our security lead, found a good architecture, with a lot of feedback from a number of other team members of course. This has been a real collaborative effort, building on our years of experience and a good understanding of the needs of our users and customers.

How does it work?

The feature consists of several components. There is the actual encryption and decryption code which is implemented in the Nextcloud iOS and Android apps and in the Mac, Windows and Linux clients. And then there is a server component which is implemented as a Nextcloud app to do the key management. This is useful to make it easy for the users to distribute private and public keys to all clients and share with each other. Obviously the private keys are encrypted with very strong auto generated passwords which are only known by the users and clients and are never accessible by the server. The key server also supports an optional recovery key which can be activated to make it possible to recover lost passwords/keys. This feature can be activated or deactivated to balance user convenience and security. The clients will warn users when the feature is or gets enabled.

End to end encryption can be activated by the users on a folder by folder basis. Once a user decided to encrypt a folder everything inside the folder will be encryption including the content of the files and folder and the metadata like filenames. From now on the folder is no longer accessible from the Nextcloud web-interface and WebDAV. But it is still fully readable and writable from iOS, Android and Mac, Windows, Linux. Sharing still works via public keys of other users. The full design is explained here and the architecture is further documented here

Enterprise ready

It was a key requirement to implement this feature in a way that it is not only useful for home users who want to protect their data on home-servers or at service providers. It had to be done in a way that it is useful for companies and other large organisation. We had conversations with some of our bigger customers over the last few month to make sure that this integrated nicely into the enterprise infrastructure and is compliant with existing policies. One example is that we will try to integrate this into Desktops like KDE, Gnome, Mac and Windows and will support Hardware Security Modules.

Where are we today?

This feature will be fully production ready and included in Nextcloud 13 which will be out later this year. But we didn’t want to wait until then and announce and release something as soon as possible so we can get feedback from encryption experts and the wider infosec community. So today we have our architecture document ready here. The server component is fully implemented and can be found in our github. There is a preview version of the Android app available which is fully working. The Desktop client and the iOS app are in the middle of the development. You can expect preview builds in the next few days. You can see the development and give feedback in the repositories in github.

More information can be found here:

• Nextcloud introduces native integrated end to end encryption
• End to End encryption RFC

The software can be found here:

• Server
• Android
• iOS
• Desktop

So please give feedback about the architecture and the code if you want to get involved. This is a big step forward to protect the data of users and companies against hackers and organisations who want to abuse it in various ways!

 

 

After had some headache because of learning for a logic gate :D. I tried again to solving old case why openSUSE container on docker can’t running systemd.

So, I have run openSUSE container on docker. But when I start the container, systemd can’t be running because of this error.

Failed to connect to bus: No such file or directory.

I have tried many ways to solve it, but it still can’t after i found a miracle :D. Thank you, reszelas!

Obviously, the problem is simple. Normally when you run a container you aren’t running an init system. systemctl is a process that communicates with systemd over dbus. If you aren’t running dbus or systemd, I would expect systemctl to fail. So, in openSUSE container, dbus and sysvinit are not installed.

You need to install that dependency and run some command to running systemctl on your container. For easy ways, you can build it using Dockerfile and use official images.

Below is following step to enable systemd on your openSUSE Docker Container :

• Build a container using Dockerfile, copy following content for your Dockerfile:

FROM opensuse:latest
MAINTAINER Some people 

RUN zypper install -y dbus-1 systemd-sysvinit
RUN cp /usr/lib/systemd/system/dbus.service /etc/systemd/system/; \
    sed -i 's/OOMScoreAdjust=-900//' /etc/systemd/system/dbus.service

VOLUME ["/sys/fs/cgroup", "/run"]

CMD ["/sbin/init"]

Then, build it :

docker build -t opensuse423 .

Run the container:

docker run -d --name=opensuse-systemd --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro opensuse423;
docker exec -it opensuse-systemd bash

Finally, you can run systemd on your openSUSE container, you can check by running systemctl commands, like restart your service or etc. for example :

systemctl list-units

Thank you, i will get back to work :D.

The post How To Running Systemd on openSUSE Docker Container appeared first on dhenandi.com.

RGB LEDs do not exist according to Linux LED subsystem. They are modeled as three separate LEDs, red, green and blue; that matches the hardware.

Unfortunately, it has problems. Lets begin with inconsistent naming: some drivers use :r suffix, some use :red. There's no explicit grouping of LEDs for one light -- there's no place to store parameters common for the light. (LEDs could be grouped by name.)

RGB colorspace is pretty well defined, and people expect to set specific colors. Unfortunately.... that does not work well with LEDs. First, LEDs are usually not balanced according to human perception system, so full power to the LEDs (255, 255, 255) may not
result in white. Second, monitors normally use gamma correction before displaying color, so (128, 128, 128) does not correspond to 50% of light being produced. But LEDs normally use PWM, so (128, 128, 128) does correspond to 50% light. Result is that colors are completely off.

I tested HSV colorspace for the LEDs. That would have advantage of old triggers being able to use selected colors... Unfortunately, on N900, white color is something like 15% blue, which would result in significantly reducing number of white intensities we can display.

A dream comes true; a smartphone focused on security and privacy and fully based on open source technology.

This is what the Purism Librem 5 is planned to become: the first smartphone completely build on top of open source software and open source compatible hardware. Lately the project got a lot of attention as of KDE and GNOME announcing their partnership with Purism for the Librem 5.

As the fund raising campaign for the Librem 5 is still in need for backers it’s now up to all those...

Well it’s been many many years and many many releases that we’ve been carrying a large number of patches for the cloud-init package in openSUSE and SUSE Linux Enterprise. I remember the first semi serious implementation of SLES support happened when I worked with HP to get SLES into the HP Public Cloud offering, which was based on OpenStack. The offer was eventually named Helion Public Cloud and then eventually shut down. Yes, it’s been many many years and I have received many questions about when is SUSE support going to be upstreamed, and my answer was always, “when I get around to it“. Well, it finally happened, in big part thanks to the cloud-init summit which was held for the first time earlier this year. Google in Seattle was a great host and I very much appreciate that I was invited.

Anyway, long story short spending some face time with other contributors and working out the kinks that existed in the pipeline worked wonders.  Rather than sending a small patch here and there the main implementation for openSUSE and SLE, lots of code, were accepted shortly after the cloud-init summit and over the last couple of days another couple of patches took us another step forward.

There are a few more loose ends that need work but with 17 patches removed from the package build, currently building in Cloud:Tools:Next in OBS we’ve made major progress.

Well, I for one am happy about this, and those that want to install from source can do so and have openSUSE and SLE support working from the upstream sources and not just from the packages included with openSUSE and SLE.

Thanks to Canonical for organizing the summit to get everyone together and thanks to Google for hosting the summit.

Oh and before I forget, getting the changes accepted was not the only major step forward, openSUSE Leap 42.3 will, in the not too distant future, like in the next couple of days, be integrated into cloud-init testing using containers the lxd project builds, go figure who knew these even existed.

For a long time, I wanted a phone that runs Unix. And I got that, first Android, second Maemo on Nokia N900. With Android I realized that running Linux kernel is not enough. Android is really far away from normal Unix machine, and I'd argue away from anything usable, too. Maemo was slightly closer, and probably could be fixed if it was open-source.

But I realized Linux kernel is not really the most important part. There's more to Unix: compatibility with old apps, small programs where each one does one thing well, data in text formats so you can put them in git. Maemo got some parts right, at least you could run old apps in a useful way; but most important data on the phone (contacts, calendar) were still locked away in sqlite.

And that is something I'd like to change: phone that is ssh-friendly, text-editor-friendly and git-friendly. I call it "Unicsy phone". No, I don't want to do phone `cat addressbook | grep Friend | cut -f 1`... graphical utilities are okay. But console tools still should be there, and file formats should be reasonable.

So there is tui project, and recently postmarketos project appeared. Nokia N900 is mostly supported by mainline kernel (with exceptions of bluetooth and camera, everything works). There's work to be done, but it looks doable.

More is missing in the userspace. Phone parts need work, as expected. What is more surprising... there's emacs org mode, with great calendar capabilities, but I could not find matching application to display data nicely and provide alerts. Situation is even worse for contacts; emacs org can help there, too, but there does not seem to be agreement that this is the way to go. (And again, graphical applications would be nice).

I had to apply a fix for a FCoE module in YaST, and I had no idea.

After learning a couple of things I still only have a vague idea, but I am writing it down to help my future self, my team mates, and perhaps you too.

FCoE stands for "Fibre channel over Ethernet". Apparently if you have some disk on a Fibre Channel SAN (storage area network), you can use FCoE to extend the reachability of that disk to the ethernet parts of your network. It still needs to be a kind of special ethernet (10Gb, with special network cards) but that seems less special than FC hardware.

For a better overview, including a diagram, see: SUSE Linux Enterprise Server Documentation / Storage Administration Guide / Fibre Channel Storage over Ethernet Networks: FCoE.

FCoE typically uses a virtual LAN, (VLAN, IEEE 802.1Q).

There needs to be a Fibre Channel Forwarder (FCF) between the FC and ethernet parts. It has a MAC address. Note a difference from iSCSI which works on the IP level, one layer up.

YaST helps you set things up. The rest of this article could be useful if you cannot use YaST for some reason.

SLES uses open-fcoe. On SLES-12 the package is called fcoe-utils.

fipvlan (stands for FCoE Initialization Protocol VLAN discovery) shows FCFs and which interface and VLAN they are reachable with:

# fipvlan --auto
Fibre Channel Forwarders Discovered
interface       | VLAN | FCF MAC
------------------------------------------
eth1            | 500  | 00:0d:ec:b3:ca:00

It can also --create the VLAN interface and --start up the FCoE connection, but it won't make that permanent for the next boot

To make it permanent you need to

1. enable the FCoE service (SLE11:/etc/init.d/boot.fcoe, SLE12: fcoe.service). Under the hood it uses two programs: fcoemon is the daemon, fcoeadm is a front end (fcoeadm -p shows the pid of fcoemon).
2. write a config file, /etc/fcoe/cfg-*IFACE*, where IFACE is
   • eth1.500 if AUTO_VLAN is no; in this case, you also need /etc/sysconfig/network/ifcfg-eth1.500, see man ifcfg-vlan.
   • eth1 if AUTO_VLAN is yes; in this case, the interface is named eth1.500-fcoe. Note the unusual -fcoe suffix!

With the config files in place, rcfcoe start (and ifup eth1.500, unless AUTO_VLAN). Then you should see the disk devices:

# fcoeadm --target
    Interface:        eth1.500
    Roles:            FCP Target
    Node Name:        0x50060160BB600160
    Port Name:        0x500601663B600160
    Target ID:        0
    MaxFrameSize:     2048
    OS Device Name:   rport-2:0-2
    FC-ID (Port ID):  0x710D00
    State:            Online

    LUN ID  Device Name   Capacity   Block Size  Description
    ------  -----------  ----------  ----------  ----------------------------
         0  /dev/sdb      16.00 GiB      512     DGC VRAID (rev 0430)
[...]

People who actually know their way around FCoE will note that I have omitted many important details. Let me know in the comments whether I should come back to this and expand on some topics.