If your are into devops or someone who take care backend of NGINX, you will notice there is limit of tools to read / transform NGINX access or error log files into colorize which is helpful and readable, compare to Httpd / Apache which have tonnes of script and tools to colorize your logs.

The last time I configuring NGINX was 4 years ago and yesterday I setup webserver for my client using NGINX instead of Httpd / Apache, after 7 minutes port 80 was open to public, I notice slowness on my client VPS machine, so I assume maybe some massive bots are scanning this webserver for some reason.

I open NGINX log with my favourite less- R command line and I feel awful and ackward. Do you know why? Because I been involve with lot of programming framework and tool that offer me ANSI colorize log.

If you are just like me, then I suggest you to install ccze! Here some currrent info from Fedora repository

[rnm@robbinespu ~] $ sudo dnf info ccze
Last metadata expiration check: 0:00:13 ago on Thu 22 Aug 2019 11:55:41 AM +08.
Available Packages
Name         : ccze
Version      : 0.2.1
Release      : 22.fc30
Architecture : x86_64
Size         : 81 k
Source       : ccze-0.2.1-22.fc30.src.rpm
Repository   : fedora
Summary      : A robust log colorizer
URL          : http://bonehunter.rulez.org/CCZE.html
License      : GPLv2+
Description  : CCZE is a roboust and modular log colorizer, with plugins for apm,
             : exim, fetchmail, httpd, postfix, procmail, squid, syslog, ulogd,
             : vsftpd, xferlog and more.

Like it said, this is a robust and modular log colorizer and comes with few plugins. It available on Fedora, Debian, Ubuntu, Centos, Opensuse and others distro repository.

Just install it:

$ sudo dnf install ccze #for Red Hat/CentOS/Fedora based
$ sudo apt install ccze #for Debian/Ubuntu based

and to use it, you need to open your file reader and pipe into ccze. For example:

$ sudo less -R /var/log/nginx/access.log | ccze -A | less -R 

You may check helps for more option how to manipulate and using ccze

$ ccze --help
Usage: ccze [OPTION...]
ccze -- cheer up 'yer logs.

  -a, --argument=PLUGIN=ARGS...   Add ARGUMENTS to PLUGIN
  -A, --raw-ansi             Generate raw ANSI output
  -c, --color=KEY=COLOR,...  Set the color of KEY to COLOR
  -C, --convert-date         Convert UNIX timestamps to readable format
  -F, --rcfile=FILE          Read configuration from FILE
  -h, --html                 Generate HTML output
  -l, --list-plugins         List available plugins
  -m, --mode=MODE            Change the output mode
                             (Available modes are curses, ansi and html.)
  -o, --options=OPTIONS...   Toggle some options
                             (such as scroll, wordcolor and lookups,
                             transparent, or cssfile)
  -p, --plugin=PLUGIN        Load PLUGIN
  -r, --remove-facility      remove syslog-ng's facility from start of the
                             lines
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.

Report bugs to <algernon@bonehunter.rulez.org>.

Cheers and have fun!

Dear Community,

After six years on the openSUSE Board and five as its Chairperson, I have decided to step down as Chair of the openSUSE Board effective today, August 19.

This has been a very difficult decision for me to make, with reasons that are diverse, interlinked, and personal. Some of the key factors that led me to make this step include the time required to do the job properly, and the length of time I’ve served. Five years is more than twice as long as any of my predecessors. The time required to do the role properly has increased and I now find it impossible to balance the demands of the role with the requirements of my primary role as a developer in SUSE, and with what I wish to achieve outside of work and community. As difficult as it is to step back from something I’ve enjoyed doing for so long, I am looking forward to achieving a better balance between work, community, and life in general.

Serving as member and chair of the openSUSE Board has been an absolute pleasure and highly rewarding. Meeting and communicating with members of the project as well as championing the cause of openSUSE has been a joyous part of my life that I know I will miss going forward.

openSUSE won’t get rid of me entirely. While I do intend to step back from any governance topics, I will still be working at SUSE in the Future Technology Team. Following SUSE’s Open Source policy, we do a lot in openSUSE. I am especially looking forward to being able to focus on Kubic & MicroOS much more than I have been lately.

As I’m sure it’s likely to be a question, I wish to make it crystal clear that my decision has nothing to do with the Board’s ongoing efforts to form an independent openSUSE Foundation.

The Board’s decision to form a Foundation had my complete backing as Chairperson, and will continue to have as a regular openSUSE contributor. I have absolute confidence in the openSUSE Board; Indeed, I don’t think I would be able to make this decision at this time if I wasn’t certain that I was leaving openSUSE in good hands.

On that note, SUSE has appointed Gerald Pfeifer as my replacement as Chair. Gerald is SUSE’s EMEA-based CTO, with a long history as a Tumbleweed user, an active openSUSE Member, and upstream contributor/maintainer in projects like GCC and Wine.

Gerald has been a regular source of advice & support during my tenure as Chairperson. In particular, I will always remember my first visit to FOSDEM as openSUSE Chair. Turning up more smartly dressed than usual, I was surprised to find Gerald, a senior Director at SUSE, diving in to help at the incredibly busy openSUSE booth, and doing so dressed in quite possibly the oldest and most well-loved openSUSE T-shirt I’ve ever seen. When booth visitors came with questions about SUSE-specific stuff, I think he took some glee in being able to point them in my direction while teasingly saying “Richard is the corporate guy here, I’m just representing the community..”

Knowing full well he will continue being so community minded, while finally giving me the opportunity to tease him in return, it is with a similar glee I now hand over the reigns to Gerald.

As much as I’m going to miss things about being chairperson of this awesome community, I’m confident and excited to see how openSUSE evolves from here.

Keep having a lot of fun,

Richard

Note: This announcement has been cross-posted in several places, but please send any replies and discussion to the opensuse-project@opensuse.org Mailinglist. Thanks!

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.

Kata Containers is an open source container runtime that is crafted to seamlessly plug into the containers ecosystem.

We are now excited to announce that the Kata Containers packages are finally available in the official openSUSE Tumbleweed repository.

It is worthwhile to spend few words explaining why this is a great news, considering the role of Kata Containers (a.k.a. Kata) in fulfilling the need for security in the containers ecosystem, and given its importance for openSUSE and Kubic.

What is Kata

As already mentioned, Kata is a container runtime focusing on security and on ease of integration with the existing containers ecosystem. If you are wondering what’s a container runtime, this blog post by Sascha will give you a clear introduction about the topic.

Kata should be used when running container images whose source is not fully trusted, or when allowing other users to run their own containers on your platform.

Traditionally, containers share the same physical and operating system (OS) resources with host processes, and specific kernel features such as namespaces are used to provide an isolation layer between host and container processes. By contrast, Kata containers run inside lightweight virtual machines, adding an extra isolation and security layer, that minimizes the host attack surface and mitigates the consequences of containers breakout. Despite this extra layer, Kata achieves impressive runtime performances thanks to KVM hardware virtualization, and when configured to use a minimalist virtual machine manager (VMM) like Firecracker, a high density of microVM can be packed on a single host.

If you want to know more about Kata features and performances:

• katacontainers.io is a great starting point.
• For something more SUSE oriented, Flavio gave a interesting talk about Kata at SUSECON 2019,
• Kata folks hang out on katacontainers.slack.com, and will be happy to answer any quesitons.

Why is it important for Kubic and openSUSE

SUSE has been an early and relevant open source contributor to containers projects, believing that this technology is the future way of deploying and running software.

The most relevant example is the openSUSE Kubic project, that’s a certified Kubernetes distribution and a set of container-related technologies built by the openSUSE community.

We have also been working for some time in well known container projects, like runC, libpod and CRI-O, and since a year we also collaborate with Kata.

Kata complements other more popular ways to run containers, so it makes sense for us to work on improving it and to assure it can smoothly plug with our products.

How to use

While Kata may be used as a standalone piece of software, it’s intended use is serve as a runtime when integrated in a container engine like Podman or CRI-O.

This section shows a quick and easy way to spin up a Kata container using Podman on openSUSE Tumbleweed.

First, install the Kata packages:

$ sudo zypper in katacontainers

Make sure your system is providing the needed set of hardware virtualization features required by Kata:

$ sudo kata-runtime kata-check

If no errors are reported, great! Your system is now ready to run Kata Containers.

If you haven’t already, install podman with:

$ sudo zypper in podman

That’ all. Try running a your first Kata container with:

$ sudo podman run -it --rm --runtime=/usr/bin/kata-runtime opensuse/leap uname -a
Linux ab511687b1ed 5.2.5-1-kvmsmall #1 SMP Wed Jul 31 10:41:36 UTC 2019 (79b6a9c) x86_64 x86_64 x86_64 GNU/Linux

Differences with runC

Now that you have Kata up and running, let’s see some of the differences between Kata and runC, the most popular container runtime.

When starting a container with runC, container processes can be seen in the host processes tree:

...
10212 ?        Ssl    0:00 /usr/lib/podman/bin/conmon -s -c <ctr-id> -u <ctr-id>
10236 ?        Ss     0:00  \_ nginx: master process nginx -g daemon off;
10255 ?        S      0:00      \_ nginx: worker process
10256 ?        S      0:00      \_ nginx: worker process
10257 ?        S      0:00      \_ nginx: worker process
10258 ?        S      0:00      \_ nginx: worker process
...

With Kata, container processes are instead running in a dedicated VM, so they are not sharing OS resources with the host:

...
10651 ?        Ssl    0:00 /home/marco/go/src/github.com/containers/conmon/bin/conmon -s -c <ctr-id> -u <ctr-id>
10703 ?        Sl     0:01  \_ /usr/bin/qemu-system-x86_64 -name sandbox-<ctr-id> -uuid e54ee910-2927-456e-a180-836b92ce5e7a -machine pc,accel=kvm,kernel_ir
10709 ?        Ssl    0:00  \_ /usr/lib/kata-containers/kata-proxy -listen-socket unix:///run/vc/sbs/<ctr-id>/proxy.sock -mux-socket /run/vc/vm/829d8fe0680b
10729 ?        Sl     0:00  \_ /usr/lib/kata-containers/kata-shim -agent unix:///run/vc/sbs/<ctr-id>/proxy.sock -container <ctr-id>
...

Future plans

We are continuing to work to offer you a great user experience when using Kata on openSUSE by:

• improving packages quality and stability,
• delivering periodic releases,
• making sure that Kata well integrates with the other container projects, like Podman and CRI-O.

As a longer term goal, we will integrate Kata in the Kubic distribution and in CaaSP, to make them some of the most complete and secure solutions to manage containers.

Given that the main development workflow for most kernel maintainers is with email, I spend a lot of time in my email client. For the past few decades I have used (mutt), but every once in a while I look around to see if there is anything else out there that might work better.

One project that looks promising is (aerc) which was started by (Drew DeVault). It is a terminal-based email client written in Go, and relies on a lot of other go libraries to handle a lot of the “grungy” work in dealing with imap clients, email parsing, and other fun things when it comes to free-flow text parsing that emails require.

*All are Linux distributions except ReactOS

Column descriptions:

• Distribution: Name of the distro
• Forum: Is there a support message board?
• Wiki: Is there a user-editable wiki?
• Community: Are there any links where I can directly contribute to the project?
• Membership: Can I become a voting member of the community?
• Bug Reporting: Is there a way to report bugs that I find?
• Mailing list: Is there an active mailing list for support, announcements, etc?
• Chat: Is there a way to talk to other people in the community directly?

What is this list?

This is the top 20 active projects distributions according to distrowatch.org in the past 12 months.

Things that I learned:

Only well-funded corporate sponsored Linux distributions (Fedora, Ubuntu, OpenSUSE) have all categories checked. That doesn’t mean that anyone is getting paid. I believe this means that employees are probably the chief contributors and that means there are more people putting in resources to help.

Some distributions are “Pat’s distribution”. Pat’s group owns it and Pat doesn’t want a steering committee or any other say in how the distro works. Though contributions by means of bug reports may be accepted.

A few distributions “outsource” resources to other distributions. Elementary allows Stack Exchange to provide their forum. Parrot Linux refers users to the Debian wiki. Mint suggests that you put in bug reports with the upstream provider unless it is a specific Mint create application.

There are a few Linux distributions that leave me scratching my head. How is this in the top 20 distros on distrowatch? There’s nothing here and the forum, if there is one, is nearly empty. Who uses this?

What do you want from an open source project?

Do you want to donate your time, make friends, and really help make a Linux distribution grow? Look at Fedora, Ubuntu, OpenSUSE, or Arch. These communities have ways to help you make this happen.

Do you want to just install a free OS on your machine and not worry about what goes into it until something breaks? Check out a Linux distribution with an active and friendly support community. Sometimes the more avenues the better. Sometimes you only need one really good and helpful forum.

Suggestions for distro owners:

Explicitly declare on your website what you want from the people who use your distribution and how they can help! Maybe you just need funding so you can quit your day job and do this full time.  Maybe you really need well written bug reports and testers. Say so and help them help you!

Did I miss something? Did I say that you have no chat but you have a thriving community on IRC? Then let me know and I will update this blog post! Also, make sure that it is visible on your page and not hidden away.