Do Open Source Projects Need a Business Model?

Open Source software is there for everyone. You only have to write it once, then everyone can use it for free. Through Open Source software, developers work for the common good, not only for a paycheck.

Of course this does not change that developers have to eat and need money to pay their bills. After a 40-hour-week of proprietary coding, not many want to spend the rest of the day coding for free.

So most Open Source software right now is written by coding enthusiasts who are not done with their passion after 8 hours in the office, or by hobbyists who earn their living otherwise.

In some areas, Open Source projects have successful business models. This is good, it makes the dreams of many developers come true, who would love to write Open Source software for a living.

Image by Vasilis van Gemert

Different Business Models for Different Environments

One way to earn money with Open Source software is to fulfill enterprise requirements. Large companies have budgets and care for compliance; this is a good way to get high-quality software, because you have to optimize performance and solve interesting problems for those companies.

Other ways are securing public funding, e.g by the European Union. Thanks to various politicians, the EU and some governments are ready to pay for public code. They also fund Open Source software in the name of science. Only the bureaucracy to apply for the funding can be complicated.

Crowdfunding can also work – Purism raised over 2 million for their Open Source smartphone, which is awaited in 2019. They also will be able to sell the hardware, which can pay for the development of the software, too.

Finally, some web projects also have the choice to become part of the quite toxic advertising bubble. Everybody has to make a living, but personally, I would rather write proprietary code than contribute to surveillance capitalism.

There are some projects which are neither interesting for public funding, nor enterprises, nor can they be commercialized for end users. They are still important for the Open Source ecosystem.

Good examples are crypto messengers like Delta Chat or Briar, replacements for Google surveillance products like F-Droid or LineageOS, and countless small libraries that don’t get the effort they need.

And if Developers Get Paid by Other Projects?

In February, this blog already reported on ownCloud’s upstream contributions – developers who get paid by ownCloud contribute to other projects, e.g. for maintenance. Thomas Müller and Thomas Boerger are maintainers for SabreDAV and Drone.

Another good example is how Dominik Schmidt from ownCloud and Hannah von Reth collaborated on KDE Craft.

Many Open Source companies give their developers a pass for 20% of their time. They can use it for learning to improve their code, playing around with other concepts, or contributions – and they can present their work to the others afterwards.

This way, the ecosystem benefits from the players who are lucky to have a business model – and those players benefit from an ecosystem of good software to build upon. It is a win-win-situation, yes – but it isn’t a vision.

A Long Term Solution to the Problem of Open Source Funding?

Contributions and collaboration across different projects are cool – but they don’t solve the fundamental problem. They may advance a project, but they don’t pay a developer’s rent. The question how to fund Open Source programming remains.

My favorite answer to this question is an unconditional basic income (UBI). Apart from its other advantages, giving everyone a sustainable and sufficient income each month would solve the developer’s rent problem.

It would give developers and other humans the opportunity to work on whatever they want to do, instead of what generates profit. As Open Source developers, we know perfectly well how the common good and profit are sometimes incompatible.

This does not solve the financial problems of all developers, of course – people with children, additional medical needs, or people living in an expensive city might need additional funds. Also testing devices can be too expensive.

Well, if a developer needs more money than what the basic income would provide, they can still work on commercial projects in the meantime. It isn’t exclusive, and you don’t lose it if you work additionally.

The basic income would still take away pressure from developers. People would have the time sovereignty to choose what they want to work on.

A truck dumps coins in the centre of the Federal Square in Bern.

This is not the space for a thorough discussion of arguments pro and contra a basic income, the Internet is already full of it.

Only one thing is clear to me: upstream contributions can solve the problem of Open Source projects not having enough funding – but they do not solve the problem of Open Source developers not having enough money.

No one will just give us a basic income, we, the Open Source community, have to fight for it. We could wait forever until politicians finally realize how important Open Source software is for our democracy. Or we join the other groups which demand a basic income, and make it happen.

Stick Together and Contribute!

Until everyone gets a basic income, it is even more important that Open Source developers collaborate. If you find a bug in one of your dependencies, don’t write a workaround – write a fix. And always be excellent to each other.

Respect to those who don’t get paid for writing Open Source software – you are heroes. We use your code, you use ours – let’s work together to create the software the world needs.

In summary, some of us have more responsibility here than others: to be able to pay their rent, commercial Open Source projects build upon a giant ecosystem of other Open Source software. They should show an effort for the ecosystem, too.

What do you think? Leave a comment below or share this on social media!

The article Opinion: How to Fund Open Source Projects was published on ownCloud.

Usually, when you just set up the Desktop Client, you add one account with one Folder Sync Connection. This way, all your files are in one place; you might exclude some of the files from syncing to save space on your computer.

This is not always useful – sometimes you want more granular options. Multiple Folder Sync Connections allow you to choose where on your computer a specific remote folder should be.

It enables you to choose any local folder on your computer, and any remote folder in your ownCloud, and keep them in sync. This has some advantages:

Use Cases for Multiple Folder Sync Connections

Sometimes you have a lot of loose files in your root folder, the top level of your hierarchy. This happens fast if you just put all miscellaneous files there; soon the folder is overcrowded. And without the virtual file system, you can’t even deselect those files from syncing – they will always stay there.

You can avoid this by only syncing the folders you need. Just add an extra Folder Sync Connection for the remote folder.

Another use case might be having an external hard drive, or several partitions (like C:\\ for programs and D:\\ for data). In this case the ownCloud directory might be too big for one of them, so you put some of the folders on the external hard drive.

You can also choose existing folders for syncing. For example if you want to keep your config files synchronized across devices; usually, the folder needs to be at a specific location, e.g. a hidden folder in %APPDATA%. ownCloud can take care of that.

And if you often need a folder from your ownCloud which is deeply buried in your folder hierarchy, it can make sense to give it a separate folder sync connection. This way, you don’t need to click through seven folders every time you need it. Instead you can sync the folder to wherever you want it.

Step by Step

You can choose an existing sync account – no need to create a new one. To add a second Folder Sync Connection to your normal sync account, open the Settings view of the Desktop Client:

You can add a Folder Sync Connection in the Settings view.

By clicking on Add Folder Sync Connection, you choose a local folder to sync. In this example I chose a configuration directory to save my config in ownCloud:

The local folder for your sync connection can be anywhere on your file system.

You also have to select a remote folder. This is where the folder will be in your ownCloud data structure. In this example it’s deep in the hierarchy, to show that only the last folder in the hierarchy is synced:

For the Folder Sync Connection, you can either choose an existing folder in your ownCloud or create a new one.

Optionally you can also enable the Virtual File System. This way, you only have virtual files on your local system, which you can download with a simple double-click. I don’t use it in this example, because it isn’t the right choice for a config directory.

Now you just have to wait until the Desktop Client has synchronized the local folder with the remote folder:

It can take a while until both sides of the connection are up to date.

That’s it! Now you can disable the synced folder in your original Folder Sync Connection. This way, you don’t have it on your computer twice; once should be enough.

If you don’t want to have the same folder on your computer twice, consider removing it in your main sync folder.

Get the Best out of the Desktop Client!

If you like this feature, take a look at the Documentation – the Desktop Client has many more features like this. There might be other good tips to improve your daily workflows.

And if you have some feedback on the usability of the Desktop Client, the developers are always happy to learn what is good for the users!

Give us feedback!

Are these tips helpful? Leave a comment below or share this post on social media!

The article Desktop Client Tips: How to Add a Folder Sync Connection was published on ownCloud.

It’s time for a new edition of the 3rd Party App Charts. Compared to the last issue there were the following changes:

Current Top Ten of the Third Party Apps in the App Center:

There were major changes between the apps. The biggest winner is Bareos, who climbed from rank 10 to 7 and moved OpenProject and Collabora Online Development Edition down one place each. Nextcloud overtook Kopano, who had already been catching up for some time. Middle places 5 and 6 were switched by OX App Suite and SuiteCRM. OpenVPN4UCS is no longer in the top 10 and was replaced by opsi. The places 7-9 are close together, so that the ranking next time is still exciting.

Browse through the Univention App Center

Der Beitrag Our Third Party Apps Charts for March 2019 erschien zuerst auf Univention.

This article was published on Univention Blog – Univention: https://www.univention.com/blog-en/2019/03/our-third-party-apps-charts-for-march-2019/

The article Our Third Party Apps Charts for March 2019 – ownCloud #1 again was published on ownCloud.

Mit der privacyIDEA ownCloud App in Version 2.5.1 ist nun eine flexiblere Authentifizierung an ownCloud mit einem zweiten Faktor möglich. Benutzer können auch sogeannte Challenge Response Token beliebig kombinieren. So kann sich ein Benutzer bspw. mit U2F-Token oder auch mit einem Email- oder SMS-Token anmelden. Dies kann interessant sein, da schwächere Anmeldeverfahren wie SMS gerne als temporäres Backup oder im Zuge eines Rollout-Prozesses verwendet werden.

Die privacyIDEA ownCloud App in Version 2.5.1 ist im ownCloud Marketplace verfügbar.

Für Kunden, die eine kritische Infrasturktur betreiben oder auf die verlässliche Funktion Ihrer ownCloud angewiesen sind, bieten wir Support und ein Service Level Agreement für die privacyIDEA ownCloud App.

Der Beitrag Flexiblere 2FA an ownCloud erschien zuerst auf NetKnights – IT-Sicherheit ~ Zwei-Faktor-Authentisierung ~ Verschlüsselung.

This article was published on NetKnights – IT-Sicherheit ~ Zwei-Faktor-Authentisierung ~ Verschlüsselung: https://netknights.it/flexiblere-2fa-an-owncloud/

The article Flexiblere 2FA an ownCloud was published on ownCloud.

To make the development process more transparent, there is an update on the new Phoenix frontend. We already told you how to write an app of your own for Phoenix – this time it’s about the ownCloud Design System, the new framework for giving Phoenix a nice look and feel.

You can use it for making both apps and themes; you just need to touch different parts of the ownCloud Design System. This article will give you an overview, so you know where to start.

The current state of Phoenix – there are already many components to create pages and apps.

Phoenix is still work in progress. But you can use vueJS to display components, which are based on UIkit. The ownCloud Design System already defines several useful components. Let’s take a look at them:

The Interactive ownCloud Design System Documentation

One great thing about the ownCloud Design System is that the documentation is interactive. It explains how it works and shows how to use the components in your app. At the same time you can preview the components and their design.

What it says: you can directly edit the components in the documentation and preview the changes.

Best take a look at it yourself. You can preview the elements here: https://owncloud.github.io/owncloud-design-system/#/Elements

Note that this is still work in progress; as of the time of this writing, some of the texts are still missing. On the other hand, it updates itself automatically when new components are added to the ownCloud Design System.

UIkit Components – the Atomic Design Approach

With Phoenix, all the components of the web interface can be dynamically ordered. You can easily decide what you want to have where, by placing the components where they belong in your vueJS code.

These components are based on UIkit components. They follow the principles of atomic design for frontend development, so we have elements, patterns, templates, and pages. To start with the smallest unit, elements:

Elements – the Atoms of Phoenix

Elements are basic items which can be used in many ways; think of them as the atoms of the web interface. Menu items, file icons, search bars, warning messages, confirmation buttons, and all the other stuff a webpage needs – they are elements.

You can find elements in the documentation, e.g. these buttons.

You can implement them easily wherever you need them. They will automatically follow the general look of the page. To get an overview what you can use them for, just take a look at the Pages.

If you need to get into the details, you might need the elements. But most of the time, you will not need that level of detail. Instead, the patterns might be all you wish for:

Patterns – Molecular Components

Patterns are groups of elements; like in molecules, in patterns you have all the necessary elements already ordered in a useful way. An example is the top bar, the side menu, and other screens which belong to the default furniture of any webpage

An example for a pattern is the navigation bar – pretty sure you will need it.

This way you don’t have to implement each single element on its own – you can reuse groups of elements. Because of this, many parts in Phoenix will look similar, and users can find their way even if they use an app they haven’t used before.

If something does not entirely fit your requirements, just tinker your own! You can take the example patterns as a model, and change them until it fits your need.

Templates – Organisms of Patterns

Templates define the layout and structure of a section. This is where you order the patterns you need to build a reusable page. The whole organism is defined here – should your page have arms and a head? Should it be able to walk, and does it need legs for it?

With templates you can put the components of your app where you need them, and where the user will see them later.

Pages – so be it, Amen

When your templates are filled with content, you can see a page. This is where arms, legs, and head come together to form the beautiful Wolpertinger you imagined. You should render a few pages to test whether your templates make the content actually look good.

The documentation mentioned above is a good example of it – you can see the pages directly rendering the code. If you build it locally, you can change every aspect of it and see how different it looks.

That’s it! Those are all the tools you need to create the layout of your ownCloud app in Phoenix.

Design Tokens – my Kingdom for a Theme

So now you know everything for creating an app layout – but what about the looks? In Phoenix, themes take care of the design. This has the advantage that on one ownCloud instance, every app looks the same.

Design tokens are where the theming happens – app developers won’t need it, but if you write a Phoenix theme, this is where you change colors, fonts, and icons.

You can choose from these colors for your components – or create a theme with your own favorite colors.

The design tokens are SCSS variables which define how components look like application-wide. When you want to choose one of them for your component, you can preview the look in the documentation.

They also include the icons. The ownCloud Design System provides an abundant set of icons already – but if you want different icons, just ship your own and use them in the design token class.

No need to make it more complicated – with themes, you can concentrate on designing instead of worrying about architecture.

There are plenty of existing icons to choose from.

Intrigued? Try it Out!

To start designing, you need an app of your own of course. Fortunately, getting started with Phoenix app development is really easy. This blogpost is a great start:

Write an ownCloud app for the new Phoenix frontend!

Did you like this blogpost? Do you have further questions? Leave something in the comments below or share this article on social media!

The article The ownCloud Design System – Phoenix Makes Frontend Development Easy was published on ownCloud.

We are so excited to bring you ownCloud Server 10.2! You can read the details of the last server release here.

With this release, you can expect the following new features:

• Advanced sharing permissions to increase flexibility and control when sharing data between groups and users.
• Secure View developed with Collabora for advanced file-sharing controls.
• More control for publicly shared links to help you avoid accidental data leakage or unwanted downloads.
• Storage encryption with master key in HSM to maximize security.
• Background job to detect changes in nested federated shares.
• Improved control over accepting federated shares from trusted servers.
• Enhanced privacy and self-service options for ownCloud users.

In this post, we will talk more about these new features in details.

1. Advanced Sharing Permissions

This feature enables app developers to implement individual sharing functions at user and group level. This is useful to enable users to apply more specific security settings to their data.

Advanced Sharing Permissions provides the foundation for mode-based document sharing such as “view-only”, “comments-only” or “enforce change tracking”. There are no limits to the fantasy of app developers, they can invent and implement all sharing permissions they can think of.

This is a very broad feature, and it can be used for a wide variety of use cases. The best example right now is SecureView, a new feature for Collabora Online:

2. Share Files With SecureView

Secure View allows ownCloud users to share sensitive data in such a way that it can only be viewed by the recipient. This is useful to keep an overview who has access to the data, and who doesn’t.

If users share data with someone else, they can choose to forbid editing, downloading, even copy/pasting and printing a shared document.

They can also choose to protect a document with watermarks. If a user opens such a document in Collabora, a watermark displays individual user information, which makes even screenshots or photos traceable.

Secure View is a Collabora Online feature, and works with documents of all common office file formats (docx/xlsx/pptx/pdf). As SecureView is only useful for companies, it is only available with an Enterprise License Key. If you are interested in its possibilities, get in touch with us.

If you want to share a document with SecureView, enable “protect with watermarks”.

3. Improved Public Links Sharing

With Server 10.2 a new permission for public links on folders becomes available. Users can allow recipients to view, download and upload contents, but not to make any changes (e.g., rename, move, collaborative editing).

The new permission Download / View / Upload can be regarded as a public file drop to distribute and gather information with a single link while preventing recipients from changing contents.

With the Download/View/Upload public link share, uploaders can neither edit nor delete uploaded files.

4. Storage Encryption With Master Key in HSM

ownCloud Server officially supports storage encryption with master keys stored in hardware security modules (HSM). In contrast to the regular master key-based storage encryption which stores the keys on the storage, storage encryption with keys in a HSM allows administrators to completely prevent anyone who has access to the storage from accessing the data stored in ownCloud.

The bundled encryption app has been adapted for HSM support and a standalone service (hsmdaemon) that connects ownCloud Server and the HSM device is available within ownCloud Enterprise Edition.

To get started with storage encryption and HSM, please get in touch with us.

If you want to know more about how ownCloud can protect your data, you can read this whitepaper about Data Protection & Privacy in ownCloud.

5. Background Job for Change Detection of Nested Federated Shares

When you share data across federated ownCloud instances, deeply nested folders are not automatically discovered for performance reasons.

This leads to issues such as the ownCloud Desktop Client is not able to synchronize newly added or changed content, for example, unless the user navigates down the hierarchy using the web interface, thereby triggering discovery manually. Additionally it is difficult to calculate the size of such folders.

In order to fix these issues while providing stronger administration to control resource usage, a new ‘occ’ command has been introduced which can be executed regularly as a background job to discover federated shares: just make a cron job for the occ incoming-shares:poll command.

6. Enhanced Federated Shares From Trusted Servers

ownCloud Server 10.0.9 introduced the Pending Shares feature. It basically allows users to decide whether or not they want to accept local user shares. Instead of just making the decision for them, it gives more control to the users.

Prior to this change, federated shares always had to be accepted manually, as they can originate from external, potentially untrusted sources. This is a secure feature but not the most convenient for some users.

ownCloud Server 10.2 introduces a global option to automatically accept federated shares originating from trusted servers. This option enables providers of several instances (e.g., an external and an internal instance) to facilitate or automate data exchange between them, not requiring users to accept shares.

This only works for trusted servers, though. For security reasons, federated shares from untrusted servers will never be accepted automatically.

To learn how to configure ownCloud to fit your needs best, take a look into the Configuring Federated Sharing Documentation.

7. Improved Privacy for ownCloud Users

Server 10.2 introduces new options for users that previously were global admin settings.

To give users more control over the sharing options in the scope of their account. Users can now override some global sharing options. They allow users to enable/disable Pending Shares independent of an instance’s global setting.

Users find the two new checkboxes in the ‘Sharing’ settings panel of personal settings. In addition to the option “Allow username autocompletion in share dialog” in the global ‘Sharing’ settings, users can now autonomously decide to opt-out from autocompletion to protect their privacy. When enabled, other users need to enter a user’s full identifier in order to be able to share with them.

Users have now more options to choose how much privacy they want to trade for usability.

In contrast to the Pending Shares options, this option is not a general override but an opt-out, meaning it can only be used when “Allow username autocompletion in share dialog” is enabled. Users find the new checkbox in the ‘Sharing’ settings panel of personal settings.

Get the Improvements Now!

Before you upgrade to the new version, you should read the upgrade best practices in the documentation. For more information, take a look at the release notes and the changelog.

Upgrade your ownCloud to 10.2.0!

What do you think about these improvements? Share this post on social media or leave a comment below:

The article ownCloud Server 10.2 Release – Power to the Users was published on ownCloud.

The struggle for democracy and civil rights is not always easy – and it certainly needs technology to succeed. Open Source software like Tor is an important tool for activists all over the world; if you can’t trust your government, you need at least software which you can trust.

Storing files online, and sharing them with the right people, can help activists in authoritarian states to enjoy freedom of speech. It’s especially important for whistleblowers; exposing crimes against humanity needs evidence, and such evidence needs to be stored securely.

Activists might need an anonymous file sharing service which is hard to shut down, and which doesn’t expose their identity to the authorities. ownCloud can be such a service, and this blog post shows how you can provide it to others while protecting your identity.

Security Considerations – What Can You Protect Yourself Against?

Online Security can never be fully complete. There is so much to think of, and you can only protect yourself against certain threat models. There is always a compromise who you trust and who not. Paranoia is a virtue in times of fully automated global surveillance; but we should take care not to become crazy in the process of resisting it.

That’s why this blog post defines a clear threat model: it aims to help groups of activists who work on political topics underground, and don’t want to be discovered by a surveillance state. It may require different tools to protect against corporate surveillance, or against criminal hackers.

This blog post also assumes that we can trust Let’s Encrypt certificates and Open Source projects. If it’s possible to hide backdoors in the open, we have a whole load of different problems to deal with.

Because it’s easy to say “never trust your life with software”, but only you can decide which risks are worth it, and which aren’t. If you need insecure tech to warn your partners of a police raid, you would probably take the risk.

On the other hand, technology might not always protect you. If you are de-anonymized, your password strength will probably not save you. If your law enforcement is known for torture, you better run.

In the end, you have to make your own decisions; this guide hopefully helps you to better understand how to protect yourself in which situation. But it does not substitute critical thought.

The Toolbox – What You Need for This

If you want to tackle such a project, you will need a few things: a USB flash drive for Tails and some Bitcoin every month, to rent an anonymous server and a domain. I’ll explain how you can get them, and what for:

Tails – a Flash Drive for Every Situation

We need Tails to buy and manage the server we want to install ownCloud on. To use the ownCloud as soon as it is installed, a Tor Browser will suffice, but for SSH connections you have to use Tails.

Tails is a Linux operating system which runs from a USB flash drive. Tails sends all your traffic over the Tor network, obscuring your IP address. Not only HTTP(s) traffic as with the Tor Browser, but also SSH traffic.

To run Tails, you just plug it into some computer and boot from USB (for an explanation, see the Tails installation guide). Tails does not leave a trace on the computer, if you don’t mount the hard drive.

Note: everything you do with a Tails stick will be lost when you shut down afterwards, unless you configure a persistent encrypted storage and save the files there. Choose a long password you can remember.

Programs You Will Need on Tails

Tails ships KeepassX as a password manager; you should use it. To learn more about why password managers are a really good security tool, read this blogpost about using them together with ownCloud.

You will need several passwords through this guide: for your SSH key, for the DNS and server provider login, for the ownCloud admin account, for the full disk encryption of your server… generate passwords longer than 30 letters and store them in KeepassX.

The password for your encrypted persistent storage and your KeepassX password database should be long, but easy to remember. This comic has some good tips on how to make up a good passphrase:

Another advantage of Tails for our use case is that Electrum, a Bitcoin wallet, is already pre-installed in Tails. If you have a persistent encrypted storage on your Tails stick, it saves your Bitcoin Wallet, as well as your SSH and GPG keys.

Intrigued? The installation guide is really straightforward, also for people with not so much technical experience. You can read how to install it here:

But before you use Tails, you should consider this security advise for the situation we are talking about:

If Using Tor Is Dangerous or Blocked in Your Country

Tails provides a long wiki page about warnings and general security considerations. You might read them, they are a very good start to gain a better understanding of online operational security. One thing is especially important for our threat model:

If you are using Tails, your Internet Service Provider can not see what exact site you are accessing. But they will notice that someone in your home network is using the Tor network, which might be dangerous in your country.

Tor bridges protect you against this; you basically only connect to the bridge server, which proxies the traffic to the Tor network. If your state or Internet Service Provider blocks the Tor network, the Tor Bridging mode will also help you accessing the Tor network.

You can activate it when you booted the Tails stick, before you start your user session. You will need the address of a Tor bridge, which are not completely public to avoid blocking and censorship. One way is to ask the Tor project for a bridge server. You could also host it yourself on a server in a foreign country.

This is already useful to circumvent Tor blocking. But if it’s really dangerous to use Tor in your country, you might take your laptop to a public Wifi and boot Tails there, instead of accessing the Tor bridge from home.

A Pseudonymous E-Mail Address

You will probably need an E-Mail address to register an account at the hosting and/or domain provider. A trustworthy provider for that is riseup.net; if you need an invite code, you can write me an E-Mail to compl4xx@riseup.net (PGP-Key).

Bitcoin or Monero for Anonymous Payments

Bitcoin is a cryptocurrency for anonymous, decentralized, secure payments. Although I should say pseudonymous, because an attacker can try to trace back payments to you. With Tails, you don’t have to worry about your IP address leaking.

But to avoid that attackers can trace back your payments, you should either use a coin mixer or use the alternative cryptocurrency Monero instead, which has coin mixing implemented by default. For extra Security, wait a few hours before you spend the Coins; this lowers the possibility of an EABE attack.

Buying Bitcoin can be difficult or dangerous depending on your country. On certain online marketplaces you can buy bitcoin with your bank account or credit card.

If you don’t want to leave this trace, you might either buy it from local cryptocurrency nerds, or ask your supporters in other countries for donations in Bitcoin. But even in countries like Iran it’s possible to get it somehow.

Buy an Anonymous Server

There are a bunch of hosting providers who accept Bitcoin and don’t ask questions. One that is often mentioned is anonymously.io, which has an expensive, but very good offer for 2×1 TB of storage.

This is about as cheap as it gets for a dedicated server; and you need a dedicated server if you want security features like full disk encryption for your server.

If you really only want to host some images and documents, less storage might suffice. Then njal.la might be a good provider – we will also need them for the anonymous domain, so you minimize the parties you have to be involved with.

You can look around for more anonymous providers, there are plenty. This list might help you, it already lists some good providers, and mentions what criteria you have to look for.

Get an Anonymous Domain

Usually having a domain name means that your personal information is stored as publicly available WHOIS information. Some top level domains offer exceptions though, for example .org and .net.

In other cases, DNS providers allow you to register a domain name with their legal information, while still handing the control over to you. And finally there are some DNS providers which only ask for an E-Mail address.

njal.la is the best example for such a DNS provider; it was founded by Peter Sunde, one of the co-founders of the Pirate Bay, to enable online anonymity. It is most trustworthy, accepts both Bitcoin and Monero, and has a great support service.

Registering a domain name and paying with cryptocoin is very easy and straightforward.

Hidden Services – Why Not Get a .onion Domain?

Setting up a hidden service might also be a good idea, and might even save you the 15€/year for a .org domain. The main security advantage is that your users can only connect via the Tor Browser. This way, they don’t accidentally access it via a non-anonymous browser.

But that is not always a good idea. There might be situations where you desperately need a file, but don’t have a Tor Browser around, e.g. when you are having a trial, and still have to print out paperwork from some internet café.

Just telling your users that they should use a Tor Browser gives them the flexibility to choose their security model. Surveillance almost never sees everything; surveillance works because we don’t know when they are listening and when they aren’t.

Setting up a hidden service is not straightforward, and out of scope for this article. If you really need such a setup, you could look into how to run a hidden service with docker, and configure the nginx container to reverse proxy to your ownCloud container.

Prepare the Server

Now you have a Server that you can login to via SSH. Let’s assume it is a Debian server, because it is most common. You should now take some security measures to protect the server; if your government can hack it, all your efforts towards privacy will be worthless.

First, generate an SSH keypair on your Tails stick. It should be automatically stored on your encrypted persistent storage. This is what keeps the control over the server in your hand; don’t lose the SSH key. Reboot your Tails stick to make sure that the encrypted persistent storage works and your SSH key stays available.

Best you make a backup of your SSH key and your Bitcoin wallet on a Veracrypt-encrypted USB drive, and hide it in the woods, or at another place where your adversary won’t look for it. Make sure not to take a phone with you. Make sure no one is following you.

Now, as your private SSH key is secured, you can copy your public SSH key to the server and store it in ~/.ssh/authorized_keys. This way, you can login with your key instead of requiring the user password.

Keeping Your Server Secure

A good idea is configuring your SSH Server to only accept public key authentication instead of password authentication. You might also change the SSH port to evade the most annoying automated brute force attacks. For real brute force protection, you should install fail2ban and configure it for SSH.

Another good security measure is disabling SSH login for the root user, and using a normal user account for that instead. You can login as an unprivileged user, and do admin tasks either through sudo or su, which requires an attacker to find out one more password.

To protect your service in the long run, make sure to always install the most recent security upgrades.

How to Encrypt the Files?

Encrypting your files is important to protect against raids of the data center. The other reason is that you might not want to trust the hosting provider. Even if they have no reason to go after you, they might be open to bribes or cooperating with their local law enforcement, which might cooperate with your law enforcement.

The best option would be to encourage your users to use Cryptomator. This tool for End-to-End Encryption enables them also not to trust you as the admin. This is the best way how they can protect their data, but you can’t enforce or enable it.

Full Disk Encryption – Hide Your Files From Your Provider

If you want to protect your server against data center raids, you better encrypt your server hard disk. This is not completely fool-proof; the data is only secure when the server is shut down. As long as it is turned on and unlocked, the password is resting in the RAM of the machine.

Whoever has physical access to the machine can try to extract the RAM by keeping it cool, and try to find your password in there. Chances are high though that they are not technically capable to do this or that it’s too expensive; so full disk encryption might still be worth a try.

Configuring full disk encryption will vary from provider to provider; there is no guide which will work everywhere. With some providers you might have an installation daemon which allows you to encrypt the disk.

With others, you have to encrypt it after installation, which is not straightforward. This is a guide for Hetzner which might give you an idea how to do it with your provider.

Encrypting the disk is one thing; you also have to install a dropbear SSH server to the initramfs so you can unlock the disk at boot. This way, when booting the server, you first login to the dropbear SSH server, unlock the disk, log out again, and then login to your normal system.

Installing ownCloud via Docker

Now, as the server is ready, you can start installing ownCloud. Installing ownCloud is very easy with Docker. You should use Traefik as a Reverse Proxy, as it automatically takes care of TLS encryption with Let’s Encrypt certificates. There is a simple guide to get started:

When you can login to your ownCloud under your domain, with working https, we are ready so far! You might also create a backup strategy; if the server is lost for some reason, or you encounter errors after an upgrade, you will be glad to be able to just restore the backup.

Install ownCloud Apps for More Security

With this setup, you should be fine and have a secure and anonymous ownCloud setup. Be cautious and use a Tor Browser or even Tails every time you login to your admin account, and make sure to pay for your server in advance as far as possible. This way, you should be safe, and able to focus on the real struggle.

To enhance security even more, you can install ownCloud apps through the Marketplace. Most of them specifically protect your users. You could look into these apps:

• Brute Force Protection
• Password Policy
• Antivirus
• PrivacyIdea 2-Factor Authentication
• TOTP 2-Factor Authentication
• OAuth2
• Password Manager

That’s It!

I hope this blogpost was helpful. If you encounter holes in my logic, don’t hesitate to leave a comment! And please share it with people who could use this kind of knowledge.

This article was published on English – compl4xx: https://lefherz.net/2019/05/29/how-to-host-owncloud-while-staying-anonymous-through-tor/

The article How to Host ownCloud – While Staying Anonymous Through Tor was published on ownCloud.

The improvements by OnlyOffice make use of the latest advancements in ownCloud Server 10.2, advanced sharing permissions. The advanced sharing permissions allows ownCloud apps to define their own permissions. This again shows the expertise in collaboration between OnlyOffice and ownCloud.

The new update to their app brings ownCloud-exclusive sharing permissions for OnlyOffice users: share owners can allow or disallow downloading, reviewing, filling out forms, commenting, and modifying the filter in office files.

You can use these permissions in all OnlyOffice documents, presentations, and spreadsheets – more specifically the .docx, .pptx, and .xlsx file types.

Here are some more details on how this benefits users:

Download Prevention – Protect Your Data

With the download permission, you can restrict downloading the shared file that is especially useful for sensitive data. This way you can control who can download the data and who can’t.

Usually, if you share a file with one person, you never know where it ends up. They could lose it, they could get hacked, they could share it against your consent; unchecking the download permission prevents these mishaps and protects your data.

This is especially useful for companies and agencies who have to comply with data security requirements; but everyone else will benefit from the improved control over their data, too.

Allow or restrict downloading for everyone who receives your file share.

Granular Sharing Options for Collaboration on .docx Files

Depending on what feedback you want from the person you are sharing the document with, there are three other new permissions. Note that they only appear when you uncheck the “edit” permission. They are mutually exclusive, so you can only apply one of them at the same time:

With the form filling permission, you can just ask them to fill out forms, but they can’t change anything else. Internal bureaucracy will be the most common use case for this.

The comment permission allows them to state their opinion and view comments by others. This also works with spreadsheets and presentations – communication is very important for successful collaboration.

And with the review permission, they can suggest, accept, and reject changes, but can’t make normal edits. You can gather their contributions without losing clarity who wrote what. This makes for a great collaboration workflow.

Filtering in .xlsx Spreadsheets

Apart from commenting, you can allow or disallow modifying filters for OnlyOffice spreadsheets. If the user is allowed to modify filters, they can change them for everyone else who uses the file.

If you don’t grant that permission, they can still apply filters – they just don’t affect anyone else. This gif shows quite well how it works:

The modify filter permission defines whether the filter changes of a share receiver affect your filters, too.

And I Only Have to Download the App From the Marketplace?

Not quite, you need an OnlyOffice server to get this to work. You can set up OnlyOffice easily with docker, and integrate it into your ownCloud server with the OnlyOffice integration app. Or ask your admin to do it.

You can find the integration app on the Marketplace:

Get the OnlyOffice integration app on the Marketplace!

Do you like these improvements? Do you have further suggestions? Just leave a comment below or share this post on social media!

The article Improved File Sharing Permissions for OnlyOffice – New Collaboration Features Introduced! was published on ownCloud.

Kudos go to our community contributors Shashvat Kedia for bringing us the Android native file picker, and to Hannes Achleitner for enabling every app user to record and send logs as part of reporting bugs. Abel García also deserves a special mention. As an intern developer he made it possible to access ownCloud files from other Android apps.

Access Your ownCloud Files From Any Android App

A deep and smooth Integration into the operating system of your device is key when using a file sync and share solution. Even more so on mobile devices – simply because of the limitations due to small screens and rather limited multitasking capabilities.

That’s why it is important to be able to access your files where you need them. Sharing a document via a messenger app or retouching some of your photos are only two use cases. In either case it is necessary to bring a file into a third-party app. To make this happen, some file sync and share solutions require their own integration into third-party apps. With the new ownCloud Android app you now have full access to all of the files stored in your ownCloud from any Android app on your mobile device. No specific ownCloud integration required.

This is possible by the new feature “Document Provider”. Thanks to the Storage Access Framework provided by Android the ownCloud Android app can now seamlessly integrate into the Downloads app of Android 7 and 8 or the Files app of Android 9.

From now on you can not only apply actions like renaming or deleting to files/folders inside your ownCloud using Android’s default file handling app. It also allows you to access your ownCloud files from any third-party app, as long as this app has access to Android’s default app for file handling (see above). Since basically every Android app, which needs to handle files in some way or another, uses the Storage Access Framework, you can rejoice at being able to use the files stored in your ownCloud pretty much everywhere on your Android device.

To use this new feature simply select the ownCloud account appearing in the side menu of your Downloads/Files app – or when accessing a file from within a third-party app which uses the Storage Access Framework.

Here are some demonstrations of what you can do using the Document Provider integration:

Rename a file or folder

Edit a file

Delete a file

Create a folder

Android Native File Picker

Probably you have already seen the custom file picker used in the Android app to choose files and upload them, as well as the option to upload content from other apps.

To make user experience more consistent, we decided to unify these two options by using Android’s native file picker for everything. You can now enjoy the same look and feel, whether uploading files from internal storage or from other apps.

Here is how it looks:

Upload files from native storage

Upload files from other apps

Shortcut to Available Offline Files

A small but convenient improvement is the new “Available offline” item in the side menu. It allows you to access all of your offline files much easier.

Logs for Everyone

This feature may not be something every user comes into contact with. But nevertheless, it helps us to further improve the app for you.

So what is this feature and why is it important? Whenever you experience an unexpected behavior of the app (something it shouldn’t do or should do in a different way) we highly appreciate you to file a little bug report. Then we can try to fix it and improve the app. In many cases you will be asked for logs, because they can provide developers with hints about what happened and what went wrong.

In previous releases of the app, creating logs was only possible for users with debug or beta versions of the up. From now users of the official ownCloud Android app downloaded from Google Play can enable logging, too.

Since you typically only need logs if you want to file a bug, enabling logging is a bit of a hidden feature. However, activating is super simple: You first need to enable the developer menu by navigating to the app’s settings page, scrolling down to the very end and click the ownCloud app version five times. After that, you can access and send your app’s logs via the new settings menu item “Logs”.

Enable developer menu and logs

Bug Fixes and Improvements

Last but not the least, we have fixed some errors reported by our users.

You no longer have to fear that the app crashes when you clear successful/failed uploads or when creating a new folder during the upload process of new files.

Users with a notched display can now enjoy some views of the app being displayed in a better way.

Problems with folders containing brackets (“[” and “]”) in their folder names not showing the folders’ content have been solved.

Passwords containing “§” no longer cause a login attempt to fail.

Download the New Version of the ownCloud Android App

Get the app now on the Google Playstore!

Get the app now on F-Droid!

Make sure to update now, to benefit from the new features.

What do you think of this release? Share this post on social media or leave a comment below.

The article ownCloud Android 2.11.0 Release – Access Your Files from Any Android App was published on ownCloud.

We are pleased to announce the new iOS App release that brings in blazing fast functionality, improved security and integration features.

The new iOS App is available for free. You can get easily get it from the App store:

Download the app for free!

Completely New Usability Features

The new app has an improved user interface. Since the old app launched in the app store in August 2012, some time has passed, and usability conventions have changed. The new app has been designed with best UX practices in mind, and improved with constant user feedback during the beta stage.

One of the features which make navigation significantly easier is the parent folder listing. When you tap on the folder name in the top bar, it lists all its parent folders, so you can easily switch between them instead of having to go all the way up again.

View all parent folders at one glance.

You can also select multiple files at once now. Just select a few files and choose from the many file options, e.g. open them in another app, copy or duplicate them, move them around, or delete them.

You can select multiple files at once to share them.

We have built-in drag & drop support, so you also move files by holding your finger at a file, and move the file around afterward. What’s even better, is that this feature works with multiple files too!

On iPads, this goes even further:

As we built in support for iPad-multitasking-features like split screen and slide-over, you can easily move files from other apps into ownCloud, and the other way round, like you are used to from Desktop applications. This makes handling files far more intuitive and convenient.

Drag and drop files between different apps to move them around.

Drag & drop is one way to upload files into ownCloud, but there are two more. You can either select a file to upload or select multiple photos and videos in the Gallery app. This is already an improvement to the old app, but more will follow.

Select multiple photos and upload them all at once.

Having Files Is Great – but What About Viewing and Editing?

A big advancement is iOS Files integration. The ownCloud files appear in the iOS Files application which provides seamless integration in mobile versions of MS Word, Excel and other collaborative editing solutions. You can now work within the iOS Files app and carry over your work to your ownCloud app and vice-versa.

You also have the option to open many files directly in ownCloud, e.g. text files, images, videos, audio files, and documents – the built-in PDF reader even supports PDF features like table-of-contents and search.

The built-in PDF reader shows a table of contents, page thumbnails, and even allows full-text search.

There is a new sharing view which you will appreciate –  it separates link-sharing and link-copying. Try it out and provide us feedback!

You can now get private and public links at one glance.

Useful New App Settings

If you open the settings view, you will find more interesting features. You can switch themes between light, dark, and classic, for example.

Choose between different themes in the app settings.

In case you encounter issues in the iOS app, you can use the logging feature to debug what’s going on in the app, find setup problems on your ownCloud server, or with the infrastructure in-between helping you save tons of time.

Another feature many people asked for is the automatic conversion of new file formats like HEIC. These are efficient media formats, but not supported everywhere.

With the new iOS ownCloud App, you can convert them to other compatible formats that allow viewing such media files on a larger base of systems. In the settings, you can find a button to automatically convert videos and photos to common file formats before uploading.

In the settings you can find features like Themes, Logging, and Automatic Conversion.

Quick Access

One thing which aims to give you a better overview is the Quick Access panel. It displays valuable information in one place: your favorites and recently used files, all of your images and PDFs, and shared files.

The quick access panel shows recent files, favorites, and more.

And another improvement that is relevant for usability is of course up- and download. Our new architecture makes file transfers more stable, especially with an unsteady internet connection. This is very helpful on mobile devices.

Does all of this sound interesting? Try it out now!

Get it for free at the App Store!

A New Development Approach for Security

Privacy is worthless without security – your files should be handled by an app which you can trust to protect you from hackers. That’s why here at ownCloud we put an extra focus on security, and included security considerations already in the architecture planning.

Specifically, authentication is heavily secured. The new fine-grained TLS certificate trust model bases control in the hands of the user. If you encounter issues with a certificate, you can check the certificate details and decide yourself whether you deem it trustworthy.

View certificate details in the new ownCloud app.

In the settings, you can also view all trusted certificates, and revoke them if you don’t need them any longer. This minimizes the attack surface and is a healthy treatment against the understandable paranoia of the digital age.

The new app supports password managers. You can use Apple’s native keychain which is synced with iCloud to store your ownCloud password. But with iOS 12 you can also use any independent Password Manager.

Password managers make it convenient to use strong passwords. (To learn how password managers make your life easier and why you should use them, you can read this blogpost.)

Use your favorite password manager to connect to ownCloud and secure your account.

You will also get warnings if redirects happen during the authentication process, to avoid entering your credentials on the wrong page. And of course there is OAuth2 support; the OAuth2 authentication mechanism uses a ASWebAuthenticationSession, following best security practices.

Another cool security feature is that once you have switched applications, the window appears blurred in the iOS app switcher. This is useful if you want to show content from other apps to anyone who isn’t supposed to see your files.

The app is blurred in the app switcher for privacy reasons.

And of course you can protect the access to your account with a passcode, Touch ID or Face ID – that’s supported, too.

Get it at the iOS App Store Now!

To get the most out of your ownCloud, install it to your iPhone and iPad. Working with files can be so much more convenient – it makes your most memorable photos, interesting ideas, and important documents directly available.

Download it for free from the App Store!

Contribute to the Translations!

You like the app? You can help improving it even further, even without coding skills! The easiest way is to help with the Translations. If you collaborate on the app’s Transifex project, it’s super easy.

But there are more ways to improve the app, of course – just take a look at the GitHub repository. You can improve the app, or even write your own iOS app interacting with ownCloud, using the brand new SDK.

What do you think about these improvements? Leave a comment below or share this post on social media:

The article The New iOS App Is Ready For the Public – Get it for Free at the App Store! was published on ownCloud.

The first part will be about the basics and requirements of the setup, so the second part can cover the details step by step.In summary, we want to reach the following:

• Outages of the hardware should neither lead to data loss nor availability problems.
• Rising user numbers should not cause problems, or at least be easier to handle:
  • Depending on the type of storage the servers use, Ceph is very performant and shouldn’t have problems with many users.
  • Depending on which ownCloud features are used, the other possible bottleneck, the database.

What is Kubernetes?

Kubernetes is an orchestrator for containers. This means that you can run Kubernetes containers across many different servers, and ships other useful features. Apart from running containers, Kubernetes can do a lot more, e.g. make HTTP applications reachable from the Internet through the Kubernetes Ingress Feature.

The rest of this series requires some basic Kubernetes knowledge. If Kubernetes is still a Pandora’s Box for you, you can build up that knowledge through the amazing tutorials by the Kubernetes Project.

Note: the second article of the series assumes that you have a working Kubernetes cluster with at least one Node / Worker.

What Do We Need?

Let’s start with the components which you always need. We can then work ourselves up to the corresponding tools and projects which can help us to do meet those needs in the Kubernetes environment.

Database – PostgreSQL

Let’s start with the most important component, the database.

In the case of a small ownCloud instance, often SQLite is used as a database. SQLite is not made for high availability. You should think about a change to either PostgreSQL, MySQL, or Oracle in any case.

Support for the Oracle Database Server is available in the ownCloud Enterprise Edition. For more information about SQLite, see When to and not to use SQLITE – FAQ – ownCloud Central.

One of the supported databases is PostgreSQL. As there are relatively small operators in Kubernetes which can run a PostgreSQL cluster, we will use those.

But before we show the “PostgreSQL Operator”, what even is such an operator?

Simply put, an operator in Kubernetes is an automation mechanism. The operator can react to the database and create certain custom objects in Kubernetes, so called CustomResourceDefinitions.

This means as an eample for a PostgreSQL operator: when a PostgreSQL object is created, the operator reacts to it and automatically creates other Kubernetes objects (e.g. Services, Deployments, StatefulSets) to create a PostgreSQL cluster.

In this article we will use Zalando’s Postgres Operator to run a PostgreSQL cluster in Kubernetes.

Storage

ownCloud needs storage to save uploaded files. The database needs storage, too, e.g. for user logins, app data, and shares.

For ownCloud a file system storage like NFS makes the most sense. The reason for using file system storage instead of block storage is that block storage was never intended for more than for a Writer.

You could also integrate Object Storage like AWS S3 into ownCloud, but in this series we will limit ourselves to the usage of file system storage.

For PostgreSQL you should definitely use block storage though, if you want the best performance. The background is that the database can write more directly with block storage; the Linux kernel can assist with caching.

Now as we answered the question which type of storage is best for which part of the setup, let’s talk about the storage software.

The kraken is the mascot of Ceph storage.

Ceph

The Ceph Project has been around circa since 2006. The highest priority for Ceph is data security. Perfect for us, as we do not want to lose any of our valuable data, whether vacation photos, musix, or important documents.

You don’t have to worry about Ceph being continuously developed – the Ceph foundation supports Ceph centrally, to push the already strong development even more. This shows again how good it is if companies which use Open Source come together and pull in the same direction.

Ceph is very complex, but offers many features. Apart from filesystem storage, you can also use it for block storage and object storage in different protocols (e.g. S3 or OpenStack SWIFT).

A fundamental recommendation is to read the Intro to Ceph – Ceph Documentation to understand the basic concepts. CERN, Deutsche Telekom, and many other organizations and companies use Ceph as a storage system for their applications.

Most likely now the questions appears – where is Ceph supposed to run? The question is good and easily answered – in Kubernetes of course. Rook.io is the way to go here.

Rook enables Ceph to run in Kubernetes, just as other software which keeps persistent files, e.g. EdgeFS, Minio, CockroachDB and others.

Above at Database – PostgreSQL we talked about Kubernetes operators. Rook is such an operator, which reacts to Kubernetes custom objects. If it reacts on CephCluster objects, it can e.g. create a Ceph cluster in Kubernetes.

Apart from creating the Ceph cluster, at the moment Rook also takes care of creating and deleting volumes in Ceph, while managing the PersistentVolume object in Kubernetes.

For everyone who is interested in containers and Kubernetes I recommend to read about the topics Kubernetes Blog – Container Storage Interface (CSI) and Kubernetes – Persistent Volumes.

Now, as we have dealt with the storage topic, there is only one component missing: Redis.

Redis

By default, the database takes care of file locking. In the end we want to take this extra effort away from the database effort. That’s why we are going to use Redis for it. For this topic there is Transactional File Locking.

Again we are going to use an operator to make our life a bit easier. The kubedb Operator can run Redis as a Cluster in Kubernetes.

For more information about the Redis part in kubed Operator, take a look at the kubedb Documentation.

The Plan

For a final overview how this will look in Kubernetes, here is a diagram with the components:

All necessary components in our Kubernetes cluster.

To summarize it in bullet points:

• Kubernetes to run ownCloud and the other components as containers.
  • Ingress controller which depends on the Kubernetes installation, to make ownCloud accessible from the Internet.
• Zalando’s Postgres operator for PostgreSQL clusters in Kubernetes.
• kubed operator for Redis clusters in Kubernetes.
• Ceph Storage via a Rook.io container in Kubernetes.

We will execute this plan step by step in the second part of this article series, to run ownCloud in Kubernetes, redundant and highly available.

Did you like this article or do you have further suggestions? Leave a comment below or share this post on social media!

The article Running ownCloud in Kubernetes With Rook Ceph Storage was published on ownCloud.

ownCloud Conference is the place to be for ownCloud administrators and developers and those who want to become them. It will have interactive workshops, talks on interesting use cases and discussions on the future of the platform.

Share Your Knowledge and Give a Talk

The event is all about you, the ownCloud community. Please feel free to talk about your favorite app, ownCloud installation, best practices or a proposal for future architecture. Your contributions make the event such an exciting experience.

Submit Your Talk

Learn more about the Conference

Available Track Formats

• 10 minute Lightning Talks: This format is meant to highlight a new idea, show something cool or bring up a new topic for later discussion.
• 45 minute Tech Talks: This format is designed to explain or investigate a topic which needs more depth in discussion. Some interactivity is appreciated.
• Workshops with flexible length: These are hands-on exercises, ideal to share knowledge, to learn and to try things.

Presentations can address all different areas of ownCloud. However, we first and foremost welcome technical topics, as well as contributions about the social aspects of the project, community affairs or just free software in general.

Your Audience

The audience at ownCloud Conference typically ranges from hobby code enthusiasts to professional developers, designers and administrators. But attendees also include web activists, free software supporters, interested users, politicians and deciders.

Some Ideas for Your Talk

Here are some topics for which contributions would be particularly welcome.

• ownCloud core technologies on server and clients, such as file access, sharing, syncing
• Aspects of ownCloud as an application platform: best practices, APIs, fancy project ideas
• Scaling, deployment and updating: How do you grow big with ownCloud?
• Integrations: ownCloud as a good citizen in other environments, or vice versa
• Community: How to build a community around ownCloud

Please note that this list is meant to be an inspiration for you. It does not limit the talks we accept in any way. Please feel free to submit all your cool ideas.

Submit Your Talk

Learn more about the Conference

Don’t Forget to Register

The conference is free to attend, but registering is required to help us for planning the event. So head over to our conference website and get your ticket now.

We are looking forward to seeing you in Nuremberg!

The article Become a Speaker at ownCloud Conference 2019 was published on ownCloud.

ONLYOFFICE is a collaborative office suite for working with documents, spreadsheets and presentations in UCS. It is combined with either Nextcloud or ownCloud and installed from Univention App Center casually (Docker-based) or as a pre-configured virtual appliance. You can also integrate it in UCS LDAP to manage all users. Read this article to learn about the latest and likely the most extensive update in ONLYOFFICE Document Server.
Free open source ONLYOFFICE Document Server has caught up with the advanced version, ONLYOFFICE Integration Edition, in functionality. This means that all features including the tabbed interface layout, Content Controls, navigation and many more are now available for small teams using the the community version of ONLYOFFICE. The update also includes novelties newly introduced in version 5.3.
For bigger organizations that rely on higher number of employees and seek professional technical support, ONLYOFFICE still offers its business-scale solution.

One interface for all

Since the last update, the community version of ONLYOFFICE Document Server acquired the tabbed interface which once marked the new era in evolution of ONLYOFFICE editors.
Here, all the features are organized in convenient tabs that resemble a common design pattern for most of today’s tab-based office interfaces. This serves many purposes:

• navigation is more intuitive, as features are grouped by function;
• panels are more spacious and informative;
• there’s more room to accommodate the existing and upcoming functionality, hence the number of features we were able to release along.

Smarter reviewing

Three modes of previewing inputs made with Track Changes are now available: Original (no changes), Markup (all changes marked) and Final (all changes accepted).
In the latest release, we also made a couple of convenient fixes: you can view the marked changes and comments in both View and Edit modes, and you cannot delete them unless they are yours.

The mechanics have also been improved. For example, we revised how the changes are marked in numbered lists, as well as added some informative attributes to the moved texts.

Watch this video to learn how reviewing works:

Go to the Collaboration tab to work with Track Changes, reviewing and Version History.

Filling forms

Open source version now supports Content Controls feature that allows creating customizable forms with fields. This was complimented by Form Filling access rights in the editors to share these forms for filling, which is at the moment available only for ownCloud users.

Content Controls can be found in Insert tab, together with other page elements and objects that you can create and manage.

Navigation

From the existing releases, we pulled up some useful navigation tools. The Navigation menu can be found on the left and allows moving between the document parts registered in the Table of Contents. For marking and finding places in your documents, you can also leave bookmarks and manage them in the bookmark menu.

Table of Contents and Bookmarks, as well as some other writing elements can be found in the References tab.

Deeper localization

Number of available document languages increased from 46 to 250, including many local versions of world languages and more types of hieroglyph-based writing. The renewed font engine processes CJK fonts for such alphabets far better than before.

That is not all, as even more novelties are to be found in all editors, such as Presenter View in presentation editor, pivot tables, more formulas and local formats in spreadsheet editor, and general performance improvements all over the suite.
If you have any questions about ONLYOFFICE functionality, feel free to comment below, or contact us at support@onlyoffice.com.

Install the latest version of ONLYOFFICE in UCS:

ONLYOFFICE with Nextcloud                                           ONLYOFFICE with ownCloud

Der Beitrag Free ONLYOFFICE given tabbed interface and other extended version features erschien zuerst auf Univention.

This article was published on Univention Blog – Univention: https://www.univention.com/blog-en/2019/07/the-new-onlyoffice-version-of-the-multilayered-user-interface-is-easy-to-use-with-ucs/

The article Free ONLYOFFICE given tabbed interface and other extended version features was published on ownCloud.

The new Media Viewer app kills two birds with one stone: it replaces both the Video Player app, and the Gallery app, which currently handles images. It is available as a free community app under the GPLv2 License.

Features – Viewing Videos and Images

Whether you want to watch your favorite movie or your vacation photos – the Media Viewer app has many features to make this as pretty, convenient, and performant as possible. Here is a summary of what the app can do:

The Media Viewer app supports many image and video formats. By default all common formats should work; some special image formats may depend on the server setup. And some video formats may not be supported by your browser.

Clicking on an image or video opens the slideshow view; you can use it to watch all videos and images in a folder. Browse through them with the arrow keys, or by swiping through them.

The slideshow works both in the Files view and in Public Links. In the slideshow, you can display an image or video in fullscreen, and even zoom into it.

The difference between zoomed and unzoomed pictures is tremendous.

If you suddenly see an image sideways, no problem – the built-in rotation functionality can take care of that. Just press on the rotate button until it has the correct orientation:

The rotate button is very usefui to deal with upside-down cameras. Or squirrels.

Another cool thing is the native SVG support – the app automatically shows vector graphics in a proper size. You can use the zoom buttons to change the size, if another one would fit better.

The app is optimized for mobile support, of course – this way, you always have the perfect view on your images and videos, no matter which device you use. You can of course also use one of the mobile apps to look at them.

The new app supports mobile devices, as well as watching videos in the slideshow.

One big improvement towards the old gallery app is regarding performance: in the slideshow, the next and previous images preload automatically, while you are still looking at the current one.

This enables you to look through the files in peace – no waiting time, no lags.

So Which App Should I Install?

The old Gallery app remains in the Marketplace, and you can still install it with the Market app. But it is not maintained anymore, so please only use it if you really need it, e.g. for compability reasons.

To install the new app, you first need to disable and remove the Gallery app and the Video Player app in your ownCloud admin settings, under “apps”. The Media Viewer will then be default app to open images and videos.

Known Issues

The new app has some known issues. You can find them in the GitHub issues. One of them is important to know:

While new public links will work out of the box through the new Media Viewer app, existing Gallery public links won’t work anymore. Don’t worry, there is a workaround to fix this.

For this, edit your .htaccess file in the ownCloud root folder and add a new rewrite rule among the existing ones or with a new block at the bottom of the file:

<IfModule mod_rewrite.c>
  RewriteEngine on  
  RewriteRule ^/apps/gallery/s/(.*)$ /s/$1 [L,R=301]
</IfModule>

So have fun with the new Media Viewer app! We are always grateful for feedback, please open an issue at GitHub. If you want to contribute through writing code or testing, take a look at our community page.

Install the App From the Marketplace!

Do you like the new app? Leave a comment below or share this post on social media!

The article Good Bye Gallery – Say Hi to the New Media Viewer! was published on ownCloud.

The first time I realized the power of Facebook was when I wanted to quit, but couldn’t bring myself to. I was so dependent on this privacy-abusing corporation, that I didn’t want to quit only for my privacy’s sake.

Finally they deleted my account, because someone reported my made-up last name. That was the second time I realized Facebook’s power. I lost a lot of friends on that day. Some of them I never found again, neither online nor offline.

The message is clear – some platforms make you dependent on them.

Nowadays, I need a Facebook profile for my job. That’s only part of how the power of platforms like Google, Amazon, Uber, and Facebook is no longer limited to the Internet. It has reached the meatspace long ago.

One example is how Facebook is blamed for endangering democracy is the Cambridge Analytica scandal 2016. And just recently, Facebook announced its own currency. The calls that Facebook and other platforms need to be held accountable grow louder by the day.

So What Exactly Is a Platform?

Michael Seemann, a philosopher with focus on the Internet, has coined the term of the platform – a paradigm of order which is about to oust the institution as central paradigm of organizing society.

Michael Seemann at the re:publica 10.

In his book Das neue Spiel, he argues that platforms are more efficient than institutions, and therefore take over their tasks, their trust, and their power. States begin to fear the power of platforms, while they don’t have fully taken over yet.

The difference to institutions is that institutions try to solve the problems of their ‘users’ directly in a micromanagement way, centrally controlled. In contrast, platforms offer their users some resources to solve their problems themselves, and automate the control.

Using an institution feels a bit like riding a train – there is a fixed route, and I can get in or not. Platforms offer me a car: they let me decide where I want to drive myself. And where institutions like a train network need central control, Uber can engage as many drivers as they want, while the control costs don’t rise.

Another good example is what Amazon did to the retail industry: when you only have limited assortment, you have to exercise control centrally. Amazon doesn’t need to care – it just offers the platform and profits.

Both institutions and platforms work by standardization; that’s how they exercise control and do their tasks. But because platforms are better in standardization and can handle more cases more efficiently, they can outperform institutions. (Das Neue Spiel, p. 99ff)

Platforms are the winners of the internet, because they have a very efficient way to exercise control. A perfect recipe for the cyberpunk dystopia which fascinates me – and which I want to avoid.

ownCloud – a Cloud Collaboration Platform

ownCloud empowers users in many ways. They don’t have to transfer files with a USB drive anymore, they don’t have to worry about Dropbox spying on them. With an OnlyOffice or Collabora integration, they can even collaborate on documents.

And in one way, ownCloud is a better platform than Facebook or Amazon – with those monopolies, if you don’t like their rules, you can only complain or leave. Those are all the participation rights users have. (Das Neue Spiel, p. 206)

There is not really a 155 HTTP error.

ownCloud offers you more autonomy, because it is Open Source: you can also host it yourself, and federate with other instances. You are not locked out of the platform just because you disagree with the admin.

Online Democracy or Admin Dictatorship?

But it remains a fact – with ownCloud, on every instance, an admin is the dictator. Because admins have the control over the deployment, they can disable every protection ownCloud could build for the users.

This makes sense in an Enterprise context – most companies have strict hierarchies. For companies, “keep your data under your control” means the control of the company owner.  Owners want to protect themselves from rogue employees and whistleblowers just as from hackers and industry espionage.

That’s why there are Enterprise apps; large companies have strict guidelines for data access, and are happy to pay for exclusive features which guarantee compliance. This model ensures that the development of the Open Source project is continued, and ownClouders can pay their rent.

With community ownCloud instances, it transfers the power to the nerds. Not everyone has the technical skills to set up an ownCloud instance themselves if they need one. This way, people without IT skills have less rights.

As an ownCloud admin, this annoys me. I would love to give more power to the users, to enable participation in my ownCloud instance. But at the moment I can only listen to feedback – the tools are missing.

An anarchist way would be to give all my users root access to my server. Unfortunately this is an IT security nightmare. Instead, the solution will be a soft one, built on communication and human interaction: the democracy app.

occ market:install democracy

In my friend’s circle we have this joke about nerds. Nerds see how technology causes political problems, so they go forth and find a technical solution for it – they don’t even think of a political solution. I’m a nerd, so I want to write an ownCloud app which takes care of democracy.

A democracy app would open options for collective decision making. All users of an ownCloud instance would be able to view transparency information in the app, discuss the ownCloud configuration, and vote on changes.

Some ideas include:

Transparency:

• Who is admin, how can I contact them?
• Which apps are installed?
• Disk usage – is my data limit fair?
• How is the server configuration?
• How much does the setup cost monthly? Who pays for it?

Discussions:

• A (minimalistic) forum with topics concerning the ownCloud server – e.g. extension requests or configuration requests.

Polls:

• Which ownCloud apps do we need?
• How big should data limits be?
• Do we want this or that configuration?
• Do we want to invite a certain user to the ownCloud or not, do we want open registrations?

Other ideas? I appreciate any feedback. Just post something into the comments, or open an issue at the GitHub repository, where I’m currently collecting ideas.

The success of such an app is highly dependent on whether the users even want to participate. E-Mail notifications for new topics would probably be good for getting traction, but that already goes far into the details.

I’m interested in your opinion: could an app like this help preventing ownCloud from becoming just another example of the emerging cyberpunk dystopia? Do I see dangers where I have nothing to fear?

Anyway, I’m really interested in writing this app. The new Phoenix frontend is approaching the first release, and I’m looking forward to build on it. If you want to contribute, please get in contact with me.

Let’s build a more democractic Internet!

What do you think? Leave your opinion in the comments below or share this post on social media!

The article Opinion: Are ownCloud Servers a Democracy or Just a Platform? was published on ownCloud.

The first part of this series explained what we need for an ownCloud deployment in a Kubernetes cluster and gave a high level overview.

You can find the example files for this guide in this GitHub repository.

Preparations

To follow this guide, you need admin access to a Kubernetes cluster with an Ingress controller. If you don’t have that already, you can follow these steps:

Kubernetes Cluster Access

If you don’t have a Kubernetes cluster, you can try using the following projects xetys/hetzner-kube on GitHub, Kubespray and others (Kubernetes documentation).

minikube is not enough when started with the default resources, be sure to give minikube extra resources otherwise you will run into problems! Be sure to add the following flags to the minikube start command: --memory=4096 --cpus=3 --disk-size=40g.

You should have cluster-admin access to the Kubernetes cluster! Other access can also work, but due to the nature of objects that are created along the way it is easier to have the cluster-admin access.

Kubernetes Cluster

Ingress Controller

WARNING: Only follow this section, if your Kubernetes cluster does not have an Ingress controller yet.

We are going to install the Kubernetes NGINX Ingress Controller.

# Taken from https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/mandatory.yaml
kubectl apply -f ingress-nginx/

The instructions shown here are for an environment without LoadBalancer Service type support (e.g., bare metal, “normal” VM provider, not cloud), for installation instructions for other environments check out Installation Guide – NGINX Ingress Controller.

# Taken from https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/provider/baremetal/service-nodeport.yaml
kubectl apply -f ingress-nginx/service-nodeport.yaml

As these are bare metal installation instructions, the NGINX Ingress controller will be available through a Service of type NodePort. This Service type exposes one or more ports on all Nodes in the Kubernetes cluster.

To get that port run:

$ kubectl get -n ingress-nginx service ingress-nginx
NAME            TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   NodePort   10.108.254.160   <none>        80:30512/TCP,443:30243/TCP   3m

In that output you can see the NodePorts for HTTP and HTTPS on which you can connect to the NGINX Ingress controller and ownCloud later.

Though as written you probably want to look into a more “solid” way to expose the NGINX Ingress controller(s), for bare metal where there is no Kubernetes LoadBalancer integration one can consider using hostNetwork option for that: bare-metal considerations – NGINX Ingress Controller.

Namespaces

Through the whole installation we will create 4 Namespaces:

• rook-ceph – For the Rook-run Ceph cluster + the Rook Ceph operator (will be created below).
• owncloud – For ownCloud and the other operators, such as Zalando’s Postgres Operator and KubeDB for Redis.
• ingress-nginx – If you don’t have an Ingress controller running yet, the namespace is used for the Ingress NGINX controller (it was already created with the Ingress Controller).

kubectl create -f namespaces.yaml

Rook Ceph Storage

Now on to running Ceph in Kubernetes, using the Rook.io project.

In the following sections make sure to use the available -test suffixed files if you have less than 3 Nodes which are available to any application / Pod (e.g., depending on your cluster the masters are not available for Pods). (You can change that, for that be sure to dig into the CephCluster object’s spec.placement.tolerations and the Operator environment variables for the discover and agent daemons. Running application Pods on the masters is not recommended though.)

Operator

The operator will take care of starting up the Ceph components one by one and also preparing of disks and health checking.

kubectl create -f rook-ceph/common.yaml
kubectl create -f rook-ceph/operator.yaml

You can check on the Pods to see how it looks:

$ kubectl get -n rook-ceph pod
NAME                                  READY   STATUS    RESTARTS   AGE
rook-ceph-agent-cbrgv                 1/1     Running   0          90s
rook-ceph-agent-wfznr                 1/1     Running   0          90s
rook-ceph-agent-zhgg7                 1/1     Running   0          90s
rook-ceph-operator-6897f5c696-j724m   1/1     Running   0          2m18s
rook-discover-jg798                   1/1     Running   0          90s
rook-discover-kfxc8                   1/1     Running   0          90s
rook-discover-qbhfs                   1/1     Running   0          90s

The rook-discover-* Pods are each one on each Node of your Kubernetes cluster, as they are discovering the disks of the Nodes so the operator can plan the actions for a given CephCluster object which comes up next.

Order and structure prevail in the realm of Kubernetes.

Ceph Cluster

This is the definition of Ceph cluster that will be created in Kubernetes. It contains the lists and options on which disks to use and on which Nodes.

If you wanna see some example CephCluster objects to see what is possible, be sure to check out Rook v1.0 Documentation – CephCluster CRD.

INFO: Use the cluster-test.yaml when your Kubernetes cluster has less than 3 schedulable Nodes (e.g., minikube)! When using the cluster-test.yaml only one mon is started. If that mon is down for whatever reason, the Ceph Cluster will come to a halt to prevent any data “corruption”.

$ kubectl create -f rook-ceph/cluster.yaml

This will now cause the operator to start the Ceph cluster after the specifications in the CephCluster object.

To see which Pods have already been created by the operator, you can run (output example from a three node cluster):

$ kubectl get -n rook-ceph pod
NAME                                                     READY   STATUS      RESTARTS   AGE
rook-ceph-agent-cbrgv                                    1/1     Running     0          11m
rook-ceph-agent-wfznr                                    1/1     Running     0          11m
rook-ceph-agent-zhgg7                                    1/1     Running     0          11m
rook-ceph-mgr-a-77fc54c489-66mpd                         1/1     Running     0          6m45s
rook-ceph-mon-a-68b94cd66-m48lm                          1/1     Running     0          8m6s
rook-ceph-mon-b-7b679476f-mc7wj                          1/1     Running     0          8m
rook-ceph-mon-c-b5c468c94-f8knt                          1/1     Running     0          7m54s
rook-ceph-operator-6897f5c696-j724m                      1/1     Running     0          11m
rook-ceph-osd-0-5c8d8fcdd-m4gl7                          1/1     Running     0          5m55s
rook-ceph-osd-1-67bfb7d647-vzmpv                         1/1     Running     0          5m56s
rook-ceph-osd-2-c8c55548f-ws8sl                          1/1     Running     0          5m11s
rook-ceph-osd-prepare-owncloudrookceph-worker-01-svvz9   0/2     Completed   0          6m7s
rook-ceph-osd-prepare-owncloudrookceph-worker-02-mhvf2   0/2     Completed   0          6m7s
rook-ceph-osd-prepare-owncloudrookceph-worker-03-nt2gs   0/2     Completed   0          6m7s
rook-discover-jg798                                      1/1     Running     0          11m
rook-discover-kfxc8                                      1/1     Running     0          11m
rook-discover-qbhfs                                      1/1     Running     0          11m

Block Storage (RBD)

Before creating the CephFS filesystem, let’s create a block storage pool with a StorageClass. The StorageClass is for the PostgreSQL, and if you want, even the Redis cluster.

INFO: Use the storageclass-test.yaml when your Kubernetes cluster has less than 3 schedulable Nodes!

kubectl create -f rook-ceph/storageclass.yaml

In case of a block storage Pool there are no additional Pods that will be started, we’ll verify that the block storage Pool has been created in the “Toolbox” section above.

One more thing to do: set the created StorageClass as default in the Kubernetes cluster by running the following command:

kubectl patch storageclass rook-ceph-block -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Now you are ready to move onto the storage for the actual data to be stored in ownCloud!

CephFS

CephFS is the filesystem that Ceph offers. With its POSIX compliance it is a perfect fit to be used with ownCloud.

INFO: Use the filesystem-test.yaml when your Kubernetes cluster has less than 3 schedulable Nodes!

kubectl create -f rook-ceph/filesystem.yaml

The creation of the CephFS will cause so called MDS daemons, MDS Pods, to be started.

kubectl get -n rook-ceph pod
NAME                                    READY   STATUS      RESTARTS   AGE
[...]
rook-ceph-mds-myfs-a-747b75bdc7-9nzwx                    1/1     Running     0          11s
rook-ceph-mds-myfs-b-76b9fcc8cc-md8bz                    1/1     Running     0          10s
[...]

Toolbox

This will create a Pod which will allow us to run Ceph commands. It will be useful to quickly check the Ceph cluster’s status.

kubectl create -f rook-ceph/toolbox.yaml
# Wait for the Pod to be `Running`
kubectl get -n rook-ceph pod -l "app=rook-ceph-tools"
NAME                                    READY   STATUS      RESTARTS   AGE
[...]
rook-ceph-tools-5966446d7b-nrw5n                         1/1     Running     0          10s
[...]

Now use kubectl exec to enter the Rook Ceph Toolbox Pod:

kubectl exec -n rook-ceph -it $(kubectl get -n rook-ceph pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') bash

In the Rook Ceph Toolbox Pod, run the following command to get the Ceph cluster health status (example output from a 7 Node Kubernetes Rook Ceph cluster):

$ ceph -s
 cluster:
   id:     f8492cd9-3d14-432c-b681-6f73425d6851
   health: HEALTH_OK

 services:
   mon: 3 daemons, quorum c,b,a
   mgr: a(active)
   mds: repl-2-1-2/2/2 up  {0=repl-2-1-c=up:active,1=repl-2-1-b=up:active}, 2 up:standby-replay
   osd: 7 osds: 7 up, 7 in

 data:
   pools:   3 pools, 300 pgs
   objects: 1.41 M objects, 4.0 TiB
   usage:   8.2 TiB used, 17 TiB / 25 TiB avail
   pgs:     300 active+clean

 io:
   client:   6.2 KiB/s rd, 1.5 MiB/s wr, 4 op/s rd, 140 op/s wr

You can also get it by using kubectl:

$ kubectl get -n rook-ceph cephcluster rook-ceph
NAME        DATADIRHOSTPATH   MONCOUNT   AGE   STATE     HEALTH
rook-ceph   /mnt/sda1/rook    3          14m   Created   HEALTH_OK

That even shows you some additional information directly through kubectl instead of having to read the ceph -s output.

Rook Ceph Summary

This is how it should look like in your rook-ceph Namespace now (example output from a 3 Node Kubernetes cluster):

$ kubectl get -n rook-ceph pod
NAME                                                     READY   STATUS      RESTARTS   AGE
rook-ceph-agent-cbrgv                                    1/1     Running     0          15m
rook-ceph-agent-wfznr                                    1/1     Running     0          15m
rook-ceph-agent-zhgg7                                    1/1     Running     0          15m
rook-ceph-mds-myfs-a-747b75bdc7-9nzwx                    1/1     Running     0          42s
rook-ceph-mds-myfs-b-76b9fcc8cc-md8bz                    1/1     Running     0          41s
rook-ceph-mgr-a-77fc54c489-66mpd                         1/1     Running     0          11m
rook-ceph-mon-a-68b94cd66-m48lm                          1/1     Running     0          12m
rook-ceph-mon-b-7b679476f-mc7wj                          1/1     Running     0          2m22s
rook-ceph-mon-c-b5c468c94-f8knt                          1/1     Running     0          2m6s
rook-ceph-operator-6897f5c696-j724m                      1/1     Running     0          16m
rook-ceph-osd-0-5c8d8fcdd-m4gl7                          1/1     Running     0          10m
rook-ceph-osd-1-67bfb7d647-vzmpv                         1/1     Running     0          10m
rook-ceph-osd-2-c8c55548f-ws8sl                          1/1     Running     0          9m48s
rook-ceph-osd-prepare-owncloudrookceph-worker-01-5xpqk   0/2     Completed   0          73s
rook-ceph-osd-prepare-owncloudrookceph-worker-02-xnl8p   0/2     Completed   0          70s
rook-ceph-osd-prepare-owncloudrookceph-worker-03-2qggs   0/2     Completed   0          68s
rook-ceph-tools-5966446d7b-nrw5n                         1/1     Running     0          8s
rook-discover-jg798                                      1/1     Running     0          15m
rook-discover-kfxc8                                      1/1     Running     0          15m
rook-discover-qbhfs                                      1/1     Running     0          15m

The important thing is that the ceph -s output or the kubectl get cephcluster output shows that the health is HEALTH_OK and that you have OSD Pods running. The ceph -s output line should say: osd: 3 osds: 3 up, 3 in (where 3 is basically the amount of OSD Pods).

Should you not have any OSD Pod, make sure all your Nodes are Ready and schedulable (e.g., no taints preventing “normal” Pods to run) and make sure to check out the logs of the rook-ceph-osd-prepare-* and of existing rook-ceph-osd-[0-9]* Pods.

If you don’t have any Pods related to rook-ceph-osd-* look into the rook-ceph-operator-* logs for error messages, be sure to go over each line to make sure you don’t miss an error message.

PostgreSQL

Moving on to the PostgreSQL for ownCloud. Zalando’s PostgreSQL operator does a great job for running PostgreSQL in Kubernetes.

First thing to create is the PostgreSQL Operator which brings the CustomResourceDefinitions, remember the custom Kubernetes objects, with itself. Using the Ceph block storage (RBD) we are going to create a redundant PostgreSQL instance for ownCloud to use.

$ kubectl create -n owncloud -f postgres/postgres-operator.yaml
# Check for the PostgreSQL operator Pod to be created and running
$ kubectl get -n owncloud pod
NAME                                 READY   STATUS    RESTARTS   AGE
postgres-operator-6464fc9c48-6twrd   1/1     Running   0          5m23s

With the operator created, move on to the PostgreSQL custom resource object that will cause the operator to create a PostgreSQL instance for use in Kubernetes:

# Make sure the CustomResourceDefinition of the PostgreSQL has been created
$ kubectl get customresourcedefinitions.apiextensions.k8s.io postgresqls.acid.zalan.do
NAME                        CREATED AT
postgresqls.acid.zalan.do   2019-08-04T10:27:59Z

The CustomResourceDefinition exists? Perfect, continue with the creation:

kubectl create -n owncloud -f postgres/postgres.yaml

It will take a bit for the two PostgreSQL Pods to appear, but in the end you should have two owncloud-postgres Pods:

$ kubectl get -n owncloud pod
NAME                                 READY   STATUS    RESTARTS   AGE
owncloud-postgres-0                  1/1     Running   0          92s
owncloud-postgres-1                  1/1     Running   0          64s
postgres-operator-6464fc9c48-6twrd   1/1     Running   0          7m

owncloud-postgres-0 and owncloud-postgres-1 in Running status? That looks good.

Now that the database is running, let’s continue to the Redis.

Redis

To run a Redis cluster we need the KubeDB Operator. You can install it with a bash script or Helm. To keep it quick’n’easy we’ll use their bash script for that:

curl -fsSL https://raw.githubusercontent.com/kubedb/cli/0.12.0/hack/deploy/kubedb.sh -o kubedb.sh
# Take a look at the script using, e.g., `cat kubedb.sh`
#
# If you are fine with it, run it:
chmod +x kubedb.sh
./kubedb.sh
# It will install the KubeDB operator to the cluster in the `kube-system` Namespace

(You can remove the script afterwards: rm kubedb.sh)

For more information on the bash script and / or the Helm installation, checkout KubeDB.

Now move on to create the Redis cluster. Run:

kubectl create -n owncloud -f redis.yaml

It will take a few seconds for the first Redis Pod(s) to be started, to check that it worked, look for Pods with redis-owncloud- in their name:

$ kubectl get -n owncloud pods
NAME                                 READY   STATUS    RESTARTS   AGE
owncloud-postgres-0                  1/1     Running   0          6m41s
owncloud-postgres-1                  1/1     Running   0          6m13s
postgres-operator-6464fc9c48-6twrd   1/1     Running   0          12m
redis-owncloud-shard0-0              1/1     Running   0          49s
redis-owncloud-shard0-1              1/1     Running   0          40s
redis-owncloud-shard1-0              1/1     Running   0          29s
redis-owncloud-shard1-1              1/1     Running   0          19s
redis-owncloud-shard2-0              1/1     Running   0          14s
redis-owncloud-shard2-1              1/1     Running   0          10s

That is how it should look like now.

ownCloud

Now the final “piece”: ownCloud. The folder owncloud/ contains all the manifests we need:

• ConfigMap and Secret for basic configuration of the ownCloud.
• Deployment to get ownCloud Pods running in Kubernetes.
• Service and Ingress to expose ownCloud to the internet.
• CronJob to run the ownCloud cron task execution (e.g., cleanup and others), instead of having the cron run per instance.

The ownCloud Deployment currently uses a custom built image (galexrt/owncloud-server:latest) which has a fix for a clustered Redis configuration issue (There is already an open pull request).

kubectl create -n owncloud -f owncloud/
# Now we'll wait for ownCloud to have installed the database to then scale the ownCloud up to `2` (or more if you want)

The admin username is myowncloudadmin and can be changed in the owncloud/owncloud-configmap.yaml file. Be sure to restart both ownCloud Pods after changing values in the ConfigMaps and Secrets.

If you want to change the admin password, edit the owncloud/owncloud-secret.yaml file line OWNCLOUD_ADMIN_PASSWORD. The values in a Kubernetes Secret object are base64 encoded (e.g., echo -n YOUR_PASSWORD | base64 -w0)!

To know when your ownCloud is up’n’running check the logs, e.g.:

$ kubectl logs -n owncloud -f owncloud-856fcc4947-crscn
Creating volume folders...
Creating hook folders...
Waiting for PostgreSQL...
wait-for-it: waiting 180 seconds for owncloud-postgres:5432
wait-for-it: owncloud-postgres:5432 is available after 1 seconds
Removing custom folder...
Linking custom folder...
Removing config folder...
Linking config folder...
Writing config file...
Fixing base perms...
Fixing data perms...
Fixing hook perms...
Installing server database...
ownCloud was successfully installed
ownCloud is already latest version
Writing objectstore config...
Writing php config...
Updating htaccess config...
.htaccess has been updated
Writing apache config...
Enabling webcron background...
Set mode for background jobs to 'webcron'
Touching cron configs...
Starting cron daemon...
Starting apache daemon...
[Sun Aug 04 13:26:18.986407 2019] [mpm_prefork:notice] [pid 190] AH00163: Apache/2.4.29 (Ubuntu) configured -- resuming normal operations
[Sun Aug 04 13:26:18.986558 2019] [core:notice] [pid 190] AH00094: Command line: '/usr/sbin/apache2 -f /etc/apache2/apache2.conf -D FOREGROUND'

The Installing server database... will take some time depending on your network, storage and other factors.

After the [Sun Aug 04 13:26:18.986558 2019] [core:notice] [pid
190] AH00094: Command line: '/usr/sbin/apache2 -f
/etc/apache2/apache2.conf -D FOREGROUND' you should be able to reach your ownCloud instance through the NodePort Service Port (on HTTP) or through the Ingress (default address owncloud.example.com). If you are using the Ingress from the example files, be sure to edit it to use a (sub-) domain pointing to the Ingress controllers in your Kubernetes cluster.

You now have a ownCloud instance running!

Further points

HTTPS

To further improve the experience of running ownCloud in Kubernetes, you will probably want to checkout Jetstack’s cert-manager project on GitHub to get yourself Letsencrypt certificates for your Ingress controller. The cert-manager allows you to request Let’s Encrypt certificates easily through Kubernetes custom objects and keep them uptodate.

Meaning the ownCloud will then be reachable via HTTPS which combined with the ownCloud encryption makes it pretty secure.

For more information on using TLS with Kubernetes Ingress, checkout Ingress – Kubernetes.

Pod Health Checks

In the owncloud/owncloud-deployment.yaml there is a readinessProbe and livenessProbe in the Deployment sepc but commented out. After the ownCloud has been installed and you have verified it is running, you can go ahead and uncomment those lines and use kubectl apply / kubectl replace (don’t forget to specify the Namespace -n owncloud).

Upload Filesize

When changing the upload filesize on the ownCloud instance itself through the environment variables, be sure to also update the Ingress controller with the “max upload file size”.

Other Configuration Options

When wanting to change config options, you need to provide them through environment variables. You can specify them in the owncloud/owncloud-configmap.yaml.

A list of all available environment variables can be found here:

• https://github.com/owncloud-docker/server#available-environment-variables
• https://github.com/owncloud-docker/base#available-environment-variables

Updating ownCloud in Kubernetes

It is the same procedure as with running ownCloud with, e.g., docker-compose.

To update ownCloud you need to scale down the Deployment to 1 (replicas), then update the image, wait for the one single Pod come up again and then scale up the ownCloud Deployment again to, e.g., 2 or more.

Summary

This is the end of the two part series on running ownCloud in Kubernetes – thanks for reading into it. Hopefully it is helpful.

Feedback is appreciated! Just leave a comment below or share this guide with others.

The article Running ownCloud in Kubernetes With Rook Ceph Storage – Step by Step was published on ownCloud.

It is a great idea to encrypt files on client side before uploading them to an ownCloud server if that one is not running in controlled environment, or if one just wants to act defensive and minimize risk.

Some people think it is a great idea to include the functionality in the sync client.

I don’t agree because it combines two very complex topics into one code base and makes the code difficult to maintain. The risk is high to end up with a kind of code base which nobody is able to maintain properly any more. So let’s better avoid that for ownCloud and look for alternatives.

A good way is to use a so called encrypted overlay filesystem and let ownCloud sync the encrypted files. The downside is that you can not use the encrypted files in the web interface because it can not decrypt the files easily. To me, that is not overly important because I want to sync files between different clients, which probably is the most common usecase.

Encrypted overlay filesystems put the encrypted data in one directory called the cipher directory. A decrypted representation of the data is mounted to a different directory, in which the user works.

That is easy to setup and use, and also in principle good to use with file sync software like ownCloud because it does not store the files in one huge container file that needs to be synced if one bit changes as other solutions do.

To use it, the cypher directory must be configured as local sync dir of the client. If a file is changed in the mounted dir, the overlay file system changes the crypto files in the cypher dir. These are synced by the ownCloud client.

One of the solutions I tried is CryFS. It works nicely in general, but is unfortunately very slow together with ownCloud sync.

The reason for that is that CryFS is chunking all files in the cypher dir into 16 kB blocks, which are spread over a set of directories. It is very beneficial because file names and sizes are not reconstructable in the cypher dir, but it hits on one of the weak sides of the ownCloud sync. ownCloud is traditionally a bit slow with many small files spread over many directories. That shows dramatically in a test with CryFS: Adding eleven new files with a overall size of around 45 MB to a CryFS filesystem directory makes the ownCloud client upload for 6:30 minutes.

Adding another four files with a total size of a bit over 1MB results in an upload of 130 files and directories, with an overall size of 1.1 MB.

A typical change use case like changing an existing office text document locally is not that bad. CryFS splits a 8,2 kB big LibreOffice text doc into three 16 kB files in three directories here. When one word gets inserted, CryFS needs to create three new dirs in the cypher dir and uploads four new 16 kB blocks.

My personal conclusion: CryFS is an interesting project. It has a nice integration in the KDE desktop with Plasma Vault. Splitting files into equal sized blocks is good because it does not allow to guess data based on names and sizes. However, for syncing with ownCloud, it is not the best partner.

If there is a way how to improve the situation, I would be eager to learn. Maybe the size of the blocks can be expanded, or the number of directories limited?
Also the upcoming ownCloud sync client version 2.6.0 again has optimizations in the discovery and propagation of changes, I am sure that improves the situation.

Let’s see what other alternatives can be found.

This article was published on Dragotin's Blog: https://dragotin.wordpress.com/2019/08/17/owncloud-and-cryfs/

The article ownCloud and CryFS was published on ownCloud.

Der Beitrag NetKnights präsentiert Mehr-Faktor-System privacyIDEA auf der it-sa erschien zuerst auf NetKnights – IT-Sicherheit ~ Zwei-Faktor-Authentisierung ~ Verschlüsselung.

This article was published on NetKnights – IT-Sicherheit ~ Zwei-Faktor-Authentisierung ~ Verschlüsselung: https://netknights.it/netknights-praesentiert-mehr-faktor-system-privacyidea-auf-der-it-sa/

The article NetKnights präsentiert Mehr-Faktor-System privacyIDEA auf der it-sa was published on ownCloud.

Renew or Die

8 years ago, in August 2011, the ownCloud Android repository received its first commit. It marked a turning point in the way of uploading files to a private cloud and sharing them with others, everything from the palm of our hands.

As it happens to all software in the world, the ownCloud app for Android was getting older. Catching up with the latest Android features was being increasingly more difficult. Besides, there were many parts of the code needing a refactoring.

Meanwhile, Android was getting more mature, modern and Kotlin was set as official language for Android development. Additionally, the Android team introduced the Android architecture components a couple of years ago, a collection of libraries to develop robust, testable and more maintainable apps.

So around a year ago, we finally gave a step forward and started to design what it would finally turn into a new architecture for the ownCloud app for Android.

Moving to a New Architecture

Before moving every kind of software to a new architecture, you should define a strategy to follow. In our case, we chose a simple use case like getting shares from server and showing them in a list and started to transform it from the old architecture to a new one – I will use this use case to explain everything related to new architecture in this blogpost.

From MVC to MVVM

Let’s introduce these two design patterns that belongs to the presentation layer and how they affect the ownCloud app for Android.

What Is the MVC Pattern?

The MVC architecture pattern (model – view – controller) is what we have traditionally been using in the ownCloud app for Android and consists of:

• Model: contains the information which the system works with and provides it to the view so it can be displayed. Besides, allows applying changes in the view from the controller. An example of model in our app is OCShare, which contains all the information needed to work with a share such as name, file path, user to share with, permissions and so on.
• Controller: responds to user actions, modifying the model when needed. It also communicates with the view to update it with the latest changes in the model. A controller in our app is ShareActivity.
• View: it presents model information to the user. Some views in our app are ShareActivity and ShareFragment.

One of the most common mistakes when implementing MVC in Android has always been using an Activity as a controller, making it responsible of tasks that should not take care of, like calling directly the model to modify data, when this should be a controller task. This is clearly a violation of the single responsibility principle and when using an Activity as a controller we are tying it to the Android platform so its code could be affected if the Activity is destroyed by the system.

If we want to properly use MVC in Android, activities and fragments should only take care of showing data and notifying user events to a controller, being the only components linked to the Android platform. Hence, controllers and models should be separate classes without any Android dependency so that can be easier to test. But this is not the case of the ownCloud app for Android since there were some activities with a controller role, assuming responsibilities that should not involve them. 

And the MVVM Pattern?

On the other hand, MVVM architecture pattern is what we are going to use in the ownCloud app for Android from now on. It consists of:

• Model: as in MVC, it represents data and business logic. The model in the ownCloud app for Android would keep being OCShare.
• View: shows information and is active, reacting to model changes, similar to an active MVC pattern. ShareActivity, ShareFragment are the views but with no controller responsibilities.
• View model: is the intermediary between model and view and contains presentation logic. There was no existing classes of this type, so we have created OCShareViewModel.

Now that we have introduced these two patterns, why have we decided to use MVVM in favor of MVC in the app? 

• In MVVM, the view will depend only on the viewmodel to get data and modify it and will directly observe changes in the model using databinding. Therefore, we will decouple code from the view.
• The model in MVC usually has many responsibilities such as obtaining data from data sources, informing the controller about changes on that data and prepare them to be displayed in the view. In MVVM, the model is totally decoupled from the view and only contains information, never actions to manipulate it.
• In MVVM, the presentation logic is handled by the viewmodel, meanwhile in MVC this responsibility is barely clear.

So with MVVM we are basically distributing responsibilities in a better way to reduce dependencies and make the code easier to test and debug.

Android Architecture Components

These components released by the Android team a couple of years ago make our life easier when it comes to implementing a MVVM pattern in Android, as well as achieving more robust, maintainable and easier to test apps. They consist of:

• LiveData: objects that notify the view when there is any change in database and are lifecycle aware so it can help us to avoid crashes when an activity is stopped. In the app we use a list of shares as livedata.
• ViewModel: responsible for preparing and handling Activity or Fragment data. It exposes the information through a LiveData observed from the view. Regarding getting shares usecase, ShareFileFragment observes changes in shares livedata.
• Room: ORM (Object-Relational mapping) library which converts SQLite to Java/Kotlin objects automatically. It allows SQL validation in compile time and returns LiveData objects to observe changes in database.

You can see below a diagram representing the getting shares use case implemented with MVVM and Android architecture components. 

So you can have a look at the diagram above and see the flow to get shares and show them in the view:

1. ShareFileFragment observes the list of shares stored in a livedata object exposed by OCShareViewModel.
2. OCShareViewModel obtains the shares from the OCShareRepository without knowing where they come from, is a completely transparent transaction, thanks to repository pattern.
3. OCShareRepository obtains the shares from OCRemoteSharesDataSource, which uses the ownCloud Android Library to fetch the shares from server. After that, it updates the database with the new shares by using OCLocalSharesDataSource.
4. As soon as new shares are available in database, ShareFileFragment  is automatically notified through the observer and shows the shares to the user.

In the diagram you will also have noticed some classes with a light blue background such as XMLLocalSharesDataSource or FirebaseRemoteSharesDataSource, which represent the extensibility of this solution that allows changing the data sources in the future and getting the shares from XML, JSON files, different APIs and so on.

Modularizing the App

MVVM and also MVC are design patterns used in the presentation layer, but an application is more than just one layer. To represent the different layers it is normal to use several modules, one for each layer.

You might be wondering what is a module here. A module is a component of an Android app that we can build, test and debug independently.

Originally, the ownCloud Android project consisted of two modules, the app itself and the library but from now on we will have four layers divided in four different modules, as you can see in the picture below.

What are the advantages of doing this modularization?

• Development scalability: several developers working in different modules independently.
• Maintainability: gradle can build the modules separately, speeding up the build process and CI.
• Less tests to run when there’s a new change: we need to run the tests in the module affected by the new change and anything else that depends on it. We do not need to run all the tests if other modules are not impacted by the changes.
• Less coupled code.
• Module switching: if in the future we want an app with a different UI and a different way to handle the information to show, we would just need to replace the :ownCloudApp module. And the same for the rest of modules, if one day we want to handle data differently to the current implementation, replacing the :ownCloudData module should be enough.

What Have We Already Achieved?

We have totally rewritten the sharing feature in Kotlin, following the architecture detailed above.

As you can see in the graphs below, we have also increased the use of Kotlin in the app if we compare it with previous versions, from 1.1% to almost 30%, without taking into account the xml resources.

This is a huge achievement because Kotlin code is easier to maintain and to read than Java. It is also safer, helping us to reduce the amount of crashes in the app for instance. In addition, it makes it easier for the community to contribute.

Tests are an important part in software development so the number of both unit and UI tests has also been increased, reaching 224 new tests.

Using a proper programming language and increasing the number of tests is decisive; but users do not usually notice this sort of changes in the app. What the users can see, among others, is the memory used by the app and how fast it reacts. 

The diagrams below shows the memory used by the app when using the share view. It is 5 MB lower than when the sharing was using the old architecture:

We have also measured how long it takes to open the share view after pressing the share icon of a file. The time has reduced as you can see below:

Next Steps

We expect that these performance improvements will also happen in the other parts of the app which will be part of the rewrite.

The next topic to address within the new architecture is the modularization of the app, as described above. To complete this modularization we would need to decouple some objects related to authorization such as the ownCloud clients and accounts.

This process will come hand in hand with a complete refactorization of the login. Afterwards, files and synchronization will be the next challenge.

Do you want to try out our current improvements? The beta is already out! Get it at the playstore:

Join the Beta testers!

What do you think about this progress? Leave a comment below or share this article on social media!

The article Re-Architecting the ownCloud App for Android was published on ownCloud.

This release brings the first part of the architecture change which is ongoing at the app. David Gonzalez, Android app developer, just wrote a great article about the new MVVM architecture of the app.

The architecture improvements are completely under the hood; this means there is not much new to see in this release for users – except less error messages and waiting times of course!

The Big Sharing Rewrite

Sharing is the first part of the app which follows the new architecture approach now. The whole part of the code which takes care of the sharing was rewritten to clean it up. Sometimes it’s more fun to tear the whole house down and build it anew!

This means that there are improvements in performance and stability. For example sharing files uses less RAM now, and opening the sharing view is faster. A quick measure how much faster it is:

The rewrite brings a gradual change to the Kotlin programming language; Sharing is now written completely in Kotlin. Kotlin makes it easier for the community to contribute; it’s also faster and more reliable than Java, leading to less crashes and other bugs.

If you want to contribute, get in touch with the Android team! ownCloud is Open Source of course, and if you miss a feature in the app, you can always write it yourself instead of waiting for it. Your help is highly appreciated, and maybe you can learn something new. Join #mobile on talk.owncloud.com if you have questions or need a hint where to start.

Download the App!

Apart from that, this release contains mostly bugfixes and small improvements – while the progress is mostly invisible to the user, David can write more than 1500 words about what they changed under the hood. It’s a big step!

To benefit from the recent improvements, upgrade the app or install it from the Google Play Store:

Get the newest release!

What do you think about these improvements? Leave a Comment below or share this post on social media!

The article ownCloud Android 2.12 Release – Sharing Rewrite was published on ownCloud.