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!

The lucky winner of the openSUSE Jeopardy and the Geeko

AppArmor Crash Course slides, 2019 edition.

To avoid getting bored ;-) I did a sub-booth featuring my other two hobbies - AppArmor and PostfixAdmin. As expected, I didn't get too many questions about them, but it was a nice addition and side job while running the openSUSE booth ;-)

I also gave an updated version of my "AppArmor Crash Course" talk. You can find the slides on the right, and the video recording (in german) on media.ccc.de.

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.

Στις 26 Αυγούστου:

Στις 27 Αυγούστου: