Install the RPM

sudo rpm -Uvh mysql80-community-release-sles12-8.noarch.rpm

Import the MySQL GnuPG Key

sudo rpm --import /etc/RPM-GPG-KEY-mysql

Install MySQL with Zypper

sudo zypper install mysql-community-server

A superuser account 'root'@'localhost' is created. A password for the superuser is set and stored in the error log file. To reveal it, use the following command:

sudo grep 'temporary password' /var/log/mysql/mysqld.log

Change the root password as soon as possible by logging in with the generated, temporary password and set a custom password for the superuser account:

mysql -u root -p

ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPassword';

The key should not be encrypted, i.e protected by a passphrase.

If there are multiple certificate files in the directory, then the one with the highest priority is chosen after sorting.

The .cert file can also contain two OpenSSL style PEM blocks. The first block containing the BEGIN CERTIFICATE for the server certificate and intermediate certificate authorities, and the second block containing BEGIN PRIVATE KEY to hold the corresponding private key.

After many years, I participated in an event organised in collaboration with the University of Mauritius. Ten years ago, around this time of the year the Linux User Group of Mauritius and the UoM Computer Club (2013) organised a Linux Festival at the Paul Octave Wiehe Auditorium. Last Saturday's Google Developers Festival (DevFest) 2023, being held on the campus of the University of Mauritius, brought back memories of those days. It also reminded me that it's been a decade since I am actively contributing to the tech community. 🎊🤓

Some happy tears flow down the cheek. Sniff!

Okay, let's talk about DevFest 2023. DevFest is an annual tech conference organised globally by the Google Developer Groups (GDG) community. This year marked the 5th edition of DevFest Mauritius. It was hosted by GDG Mauritius and the University of Mauritius (UoM). The Google Student Developer Clubs of UoM, University of Technology, Polytechnics Mauritius and the African Leadership College helped in spreading the word.

Registration for the event was done through the GDG Mauritius chapter page on the Google Developer Groups Bevy platform, while information about the event, the agenda and the speakers was also available at devfest.mscc.mu.

We had 20 speakers from different tech backgrounds — web development, mobile application development and systems/cloud engineering.

My presentation was scheduled at 11:30 a.m. in the G2 room of the Faculty of Law & Management. I started the presentation sharp on time to be able to stay both on track and on time, as for the next 45 mins, I had planned a whole journey of writing code to deploying the same on a cluster of servers.

PHP is still relevant in 2023. It still powers a lot of websites on the Internet. Even Facebook started on PHP and later created the HipHop Virtual Machine (HHVM) to compile PHP source code to HipHop bytecode for faster execution and then they created the Hack programming language.

I started the presentation by talking about PHP.

If you are just starting with PHP development, I suggest that you closely follow the works of a PHP framework, like Laravel or Symfony. I use Laravel a lot — in fact most of my web related work is now on Laravel. During the presentation I mentioned how lexpress.mu moved from Drupal to Laravel.

My next slide had a few commands needed to create a Laravel project and to run it locally (assuming that PHP and composer are already installed on that machine).

Now, that we had a codebase and we made our desired modifications to the Laravel code, it was time that we thought about packaging it and shipping it to the cloud. The easy way — containers!

SUSE Base Container Image (SUSE BCI) enters the scene. We can of course find plenty of PHP based containers to ship the code, then why SUSE BCI? The short anwser is compliance. Very often if you are working for a big company, there are rules to use software that have enterprise support. SUSE BCIs are enterprise-ready container images based on the SUSE Linux Enterprise Server (SLES). One can purchase a support subscription for the container or inherit an existing subscription from a host SUSE Linux Enterprise Server.

I talked about the Base Images and the Language Container Images. For our need to ship the Laravel codebase, we looked at the three SUSE BCIs that support PHP.

The ideal candidate was the SUSE BCI PHP-Apache 8 image. Our Laravel code is actually this year's DevFest Mauritius website. We do not require a database. The conference schedule and speakers details are pulled from a Sessionize.com API and kept as JSON locally. Therefore, a single container to run the PHP code and serve the HTTP content would be fine.

I spoke about the three SUSE BCIs for PHP and possible use cases on different types of PHP scripts or applications we may run.

Okay, it's good that we have a container to run PHP code but it's not great, yet — because it cannot run "our" PHP code. Laravel 10 requires PHP version 8.2 to run whereas the SUSE BCI has PHP version 8.0.30 as latest version.

Most Enterprise Linux distributions support packages for as long as security fixes remain available for the package. That is the case with SLES and PHP 8 here. The latest version of PHP available from the official SLE_BCI repo is PHP version 8.0.30 which will continue to receive security fixes until the end of November this year, then the package will be upgraded to version 8.1.x which will receive security fixes until November 2024.

Then, how can we use the SUSE Linux Enterprise container but with PHP version 8.2?

Comes into the scene, SUSE's own Open Build Service.

I explained how Open Build Service (OBS) allows one to compile software and package the latter for different Linux distributions and different CPU architectures. Then, I mentioned build.opensuse.org where SUSE upstream projects reside. Recently, the Linux Foundation decided to build Kubernetes packages using OBS too. I talked about how openSUSE Leap and SUSE Linux Enterprise share a 1:1 binary compatible codebase.

One could build PHP v8.2.12 packages using build.opensuse.org but... there is actually no need — because v8.2.12 is already built for SLE 15 SP5. 😎 We can simply add the OBS repo to our SLE BCI Apache-PHP container and install the latest version of PHP.

Huh! So, by this time we have a codebase, we have chosen a BCI and we know how to get the latest version of PHP running which is required for our application (i.e the website of DevFest Mauritius 2023). What's next? We need to build a container image that will hold our codebase and be ready for shipping.

So... Let's build it!

Before talking about building containers though, I mentioned that I don't like the idea of simply copying Dockerfiles from the Internet and start using. Writing a Dockerfile is not difficult and a lot of times it requires just a few lines. It also helps us keep things clean and we know what we are doing.

Let's write a Dockerfile then.

During the presentation, I explained what each line does. Especially, why I chained the RUN commands in one line instead of multiple RUN commands. Each RUN command creates an OverlayFS layer and takes up a little more space. In this example, it would have taken an additional 8MB if we had used multiple RUN commands for every CLI command specified.

FROM registry.suse.com/bci/php-apache:8

In the first line, we pull the SUSE BCI PHP-Apache 8 image. Then, we copy our project directory inside the container image at a specific path which we have specified in an Apache configuration. I talked briefly about Apache VirtualHosts.

COPY ./devfest2023 /srv/www/vhosts/devfest2023
COPY ./devfest2023.conf /etc/apache2/vhosts.d/devfest2023.conf

Next, we copy a "repo" configuration file that contains information about the OBS repository.

COPY ./obs_php.repo /etc/zypp/repos.d

The content of the .repo file is available from the PHP package project on build.opensuse.org.

We run the zypper ref command to update the repo database. We update the packages with the --allow-vendor-change option. Without this option, it will not upgrade PHP because the currently installed PHP package by vendor SUSE is the highest version available. By allowing vendor change, the package will be upgraded using newer packages from the OBS repository.

RUN zypper ref; zypper up -y --allow-vendor-change; \
zypper in -y php8-tokenizer php8-iconv php8-intl php8-bcmath \
php8-bz2 php8-ctype php8-gd php8-posix php8-readline

We install a few other PHP libraries that will be required by our Laravel application.

Laravel writes to a log file stored at the storage/laravel.log path. Therefore, ownership of the directory is changed to the user wwwrun which is the user that owns the Apache child processes.

chown -R wwwrun:wwwrun /srv/www/vhosts/devfest2023; \

We enable the mod_rewrite module in Apache because we have a Rewrite Rule in our Apache configuration that forwards all requests to the index.php file.

a2enmod rewrite

Lastly, we make the container reachable on port 80.

EXPOSE 80

Our Dockerfile is ready. We can build the container image.

I explained what each of the options does in the docker build command. After building the image, we can run a container locally to test the application.

docker run —-rm -p 8080:80 devfest:2023

Once again, I explained what each of the option in the above command does.

So, we've built a container image successfully, we've tested our application running inside a container, what do we do next? Deploy to Google Kubernetes Engine (GKE)? Not, yet. We need to push this container image to a registry, from which GKE will be able to pull and deploy.

Hereon, we started talking about the Google Cloud Platform. We needed to enable two services on GCP before we can ship a container and deploy our application. The services are:

• Artifact Registry API
• Kubernetes Engine API

I explained that previously we would use the Container Registry API but that was only limited to Docker container images. The Artifact Registry can hold repos for container images, npm packages, python, etc.

We created a repository in the Artifact Registry, we specified the format as Docker and we selected a region. We discussed about this choice (i.e region) for a while. My usual trick for obtaining the best latency to a "region" is to understand how our submarine fiber cables connect us to the rest of the world. Since, the SAFE/SAT-3/WASC submarine cable connects us to the west side of the European continent, for this example we chose the europe-west1 region, which is in Belgium. Not too far from the landing point in Portugal? 🤔 Anyway, let's continue...

After creating the repository, the GCP console redirects to the repository details page. I encircled the path which we need when pushing the container image to the registry.

Oh... wait. Before pushing our container image to the Google Artifact Registry we need to setup authentication for Docker. Read the instructions here. During the presentation I did not elaborate on the Docker/GCP authentication part as it is purely textbook instruction.

We're almost there. We have built our container, we have set up our repository on Google Cloud, so now let's do the next step.

We tag the local image devfest:2023 (which we built earlier) using the path we saw on the repository page. I explained each item in the command for clarity.

Then, we run:

docker push europe-west1-docker.pkg.dev/devfest2023-403313/mscc/devfest:2023

You can see the progress as each layer is being copied to the registry. When completed, refresh the registry page on the cloud console.

Hereon, we started talking about Kubernetes and its complexity. However, Google (and other cloud providers) offer a Managed Kubernetes Service. Managed meaning — the implementation and related complexities are obsfuscated. Thus, as a developer you should be able to deploy your application in a cluster with minimal effort. That's exactly what Google Kubernetes Engine is about.

You click on the three dots and select "Deploy to GKE".

The first option is to select a container, but here the devfest:2023 container is pre-selected. You can add environment variables which you usually do through the .env file of a Laravel application. Since, we are not using a database or require any other specific info to pass on, we can skip this part.

GKE creates a deployment configuration which defines the state of the cluster. It uses defaults here, e.g the replicas (i.e no. of nodes in the cluster) to 3. All of this information can viewed in the YAML file which is accessible from the page.

The YAML file is read-only at this point. We cannot edit the deployment configuration but we can do so once the cluster is created. Then, we can edit the YAML config to adjust it to our needs or use other "buttons" in the console to scale the cluster up/down, horizontally or vertically.

After the configuration part, the last step is to select whether we want to create a service to expose the cluster. Since, we want our application to be available on the Internet, we expose the cluster on port 80.

After we hit "DEPLOY", GKE starts building the cluster.

For this example, the cluster was ready in less than 5 mins.

Once the cluster is ready, the deployment details page will display information regarding the availability and health of the cluster nodes. At the bottom of the page, the endpoint in the Expose services show the Public IP Address for the deployment. Click on that and you can access your application. In our case, we were able to see the DevFest Mauritius 2023 site hosted on the IP address.

That was my share of contribution to DevFest Mauritius 2023, as speaker this year. I hope everybody who attended the session enjoyed it and learned at least a thing or two. 😊

A few months ago, I experimented with Ubuntu ARM64 and set up a mirror for some tests. The mirror was limited to the ARM64 architecture.

Then, this week, I was able to set up and synchronise the whole Ubuntu Ports repository, after David, the Director of cloud.mu, provisionned additional storage on the Ubuntu mirror server for an upgrade. I submitted the Ubuntu Ports mirror for review and that was completed the same day.

The mirror supports the following CPU architectures: arm64, armhf, ppc64el and s390x. When users in Mauritius install an Ubuntu server for one of these architectures the mirror is set to mu.ports.ubuntu.com in the /etc/apt/sources.list file. Being a primary mirror for Mauritius, all requests on that domain are handled by ubuntu-mirror.cloud.mu.

If you are looking for the Ubuntu ARM 64 Desktop version, then you can download it from cdimage.ubuntu.com.

FROM composer:latest AS build
WORKDIR /app
COPY . /app
RUN composer install --prefer-dist --no-dev --optimize-autoloader --no-interaction

FROM php:8.2-apache-bullseye AS production

ENV APP_ENV=production
ENV APP_DEBUG=false

RUN docker-php-ext-configure opcache --enable-opcache && \
    docker-php-ext-install pdo pdo_mysql
RUN pecl install redis && docker-php-ext-enable redis

COPY --from=build /app /app
COPY vhost.conf /etc/apache2/sites-available/000-default.conf
COPY .env.prod /app/.env

RUN cd /app && php artisan config:cache && \
    php artisan route:cache && \
    chmod 777 -R /app/storage/ && \
    chown -R www-data:www-data /app/ && \
    a2enmod rewrite

I used the above Dockerfile to build the Laravel container. There are two stages in this build process —

• First, a composer:latest container is used to install the project dependencies.
• Then, a php:8.2-apache-bullseye container is used to run the Laravel application in production.

To be honest, I should have added one more build stage to use NPM to compile the front-end stack... but... well, to better understand the reasons for multi-stage builds, let us look at something simpler.

fn main() {
    println!("Namaste, world! 🙏");
}

The above Rust code does nothing fancy, it just prints "Namaste, world!" with the folded hands emoji, to the terminal. We could pull a Rust container image, e.g rust:1.66.0-alpine3.17 to build and then run the application. It would work, right?

The rust:1.66.0-alpine3.17 container image is 787MB in size. Would you want to deploy a small binary along with a 100 times bigger container to your production environment? Probably, no. That is why we need to build the production container in multiple stages.

FROM rust:1.66.0-alpine3.17 AS build
WORKDIR /app/
COPY . .
RUN cargo build --release

FROM scratch
COPY --from=build /app/target/release/namaste-world /app/namaste-world
CMD ["/app/namaste-world"]

We use rust:1.66.0-alpine3.17 to compile the application and then we copy the binary to another smaller (very small) container, called scratch.

$ docker build . -t namaste-world:latest
[+] Building 0.1s (10/10) FINISHED                                                                                      
 => [internal] load build definition from Dockerfile                                                               0.0s
 => => transferring dockerfile: 74B                                                                                0.0s
 => [internal] load .dockerignore                                                                                  0.0s
 => => transferring context: 2B                                                                                    0.0s
 => [internal] load metadata for docker.io/library/rust:1.66.0-alpine3.17                                          0.0s
 => [internal] load build context                                                                                  0.0s
 => => transferring context: 7.29kB                                                                                0.0s
 => [build 1/4] FROM docker.io/library/rust:1.66.0-alpine3.17                                                      0.0s
 => CACHED [build 2/4] WORKDIR /app/                                                                               0.0s
 => CACHED [build 3/4] COPY . .                                                                                    0.0s
 => CACHED [build 4/4] RUN cargo build --release                                                                   0.0s
 => CACHED [stage-1 1/1] COPY --from=build /app/target/release/namaste-world /app/namaste-world                    0.0s
 => exporting to image                                                                                             0.0s
 => => exporting layers                                                                                            0.0s
 => => writing image sha256:44c98d7123b596ef4b90388ce73ee66391f5f38a04e75440dfb0a4399b436e94                       0.0s
 => => naming to docker.io/library/namaste-world:latest                                                            0.0s

Once the container is built, let's run it.

$ docker run --rm namaste-world
Namaste, world! 🙏

Now, let's have a look at the size of the container images.

$ docker images
REPOSITORY      TAG                 IMAGE ID       CREATED        SIZE
namaste-world   latest              44c98d7123b5   2 hours ago    4.57MB
rust            1.66.0-alpine3.17   87eecbd0d066   38 hours ago   787MB

See, the scratch container image holding the namaste-world binary is below 5MB while the rust:1.66.0-alpine3.17 container image is 787MB. When deploying to production it is best practice to use smaller images for less memory footprint.

Renghen and I talked after I published this post on Twitter & LinkedIn. He shared his views about having a multi-stage build process. It makes more sense if it is part of a pipeline. He does not advise compiling applications using containers. He refers to an example where the compiler requires the GPU and such compilation won't be possible using a container. However, he stated that multi-stage builds makes sense in cases where certain languages have deprecated some features and one might still need those to run an application.

• Douglas Demaio
• Patrick Fitzgerald
• Nathan Wolf
• Neal Gompa
• Chuck Payne
• Gertjan Lettink

openSUSE members can also ask questions to the candidates on the project mailing list. Vojtěch Zeisek asked the candidates about their plans and what they want to achieve with the project.

Douglas had an interesting answer. He stated that he would like to see that the openSUSE Project adopts the blockchain technology. He cited the election as an example where a smart contract could facilitate the task of running elections and maintaining an updated members list based on whether members' tokens have been used in (x) number of years.

He also mentioned NFT as something that could be explored to create a sort of badge system like the Fedora project has and member contributions could be rewarded with NFTs.

On the question about what he wishes to do, he answered that he would focus on getting the project either becoming a Foundation or transition to a decentralised autonomous organisation. Discussions about creating an openSUSE Foundation started in 2019 but it hasn't progressed much since.

I will write more about the candidates Q&A with members as they happen. If you would like to ask a question or follow the discussions, then feel free to subscribe to the project's mailing list.

Therefore, I had a quick chat with David Venter about it. For those who don't know, David is the Founder and Director of cloud.mu. His company has sponsored resources which helped me build a few Linux mirrors in Mauritius. Upon discussing about Fedora, he gave green light to set up the mirror. I peeked into the project's documentation. What we actually needed was a mirror for Fedora Linux and EPEL. The latter stands for Extra Packages for Enterprise Linux which is a Fedora Special Interest Group (SIG) that creates, maintains and manages additional packages for Enterprise Linux (comprising of RHEL, CentOS, Oracle Linux, AlmaLinux and Rocky Linux).

The Fedora Linux and EPEL mirrors became operational last week. You can see them listed at mirrors.fedoraproject.org.

The coolest part though is Mauritius showing up in the mirrors map. 😎

If you head to get.fedoraproject.org now and download an image it will pull it from the closest mirror, which is fedora-mirror.cloud.mu. In order to enable EPEL, you can follow these instructions.

Users of Fedora Linux do not need to configure anything in order to use the mirror. Fedora's mirror manager will automatically redirect requests from Mauritius to fedora-mirror.cloud.mu and fedora-epel-mirror.cloud.mu when they update their system.

There was a lot of discontentment following that announcement. Many users enjoyed the stability of CentOS and its binary compatibility with RHEL and its long term support. The news of turning CentOS into an upstream project for RHEL changed all of that.

CloudLinux is one of many CentOS supporters that was not happy with the news.

In response to the shift in project direction of CentOS, CloudLinux backed the development of AlmaLinux, a clone of RHEL. CloudLinux has been in the "Linux business" since 2009, providing a customised Linux distribution for hosting companies. Its products were mainly based on RHEL/CentOS. Thus, their commitment to the AlmaLinux project meant they would be heavily invested. In fact, CloudLinux financially backs the AlmaLinux OS Foundation.

The AlmaLinux mirror 😊

After that short history lesson, let's come to the present.

David Venter, the Founder & Director of cloud.mu, and I were having a usual "Linux mirrors" conversation and David said "we should also really do AlmaLinux". I was like, "I just read their doc, it's the easiest mirror documentation I have seen so far".

Well, the next day, David provisioned the mirror server and I did the rest of the configuration. Once the server had sync'ed completely, I submitted it to AlmaLinux for review. Soon after, almalinux-mirror.cloud.mu appeared on mirrors.almalinux.org.

If you head to almalinux.org and click on the download button, it takes you to the mirrors page and there you can see the list of the closest mirrors to you. Being in Mauritius you should see almalinux-mirror.cloud.mu at the top of that list, followed by other mirrors in Africa.

Sponsorship

Improving the Linux updates experience in Mauritius would not be possible without mirrors. I am extremely thankful to cloud.mu for the server/bandwidth sponsorship and their commitment to make Linux thrive in Mauritius.

Thus, I am assuming that Ubuntu on the ARM 64-bit architecture is not a being widely used in Mauritius. I thought it would, thinking that probably a lot of tinkerers are running experiments on a Raspberry Pi.

Ubuntu provides desktop images for the ARM 64-bit (ARMv8/AArch64) architecture on its daily build page.

I did my experiments with Ubuntu for ARM 64-bit on an Apple M1 MacOS using Parallels Desktop and a mirror server built on a Virtual Private Server (VPS) sponsored by cloud.mu.

How to use the mirror?

At the moment, the server mirrors only Ubuntu 22.04.1 LTS ARM 64-bit. Therefore, if you are using another version of Ubuntu or a different architecture, you won't be able to use the mirror. If there is interest for supporting other architectures, then it would make sense to add them, otherwise not.

So, right now, if you have an Ubuntu 22.04.1 LTS ARM 64-bit instance running, you can edit your /etc/apt/sources.list file and change all the occurrences of mu.ports.ubuntu.com and ports.ubuntu.com to ubuntu-ports.cloud.mu.

sudo sed -i 's/mu.ports.ubuntu.com/ubuntu-ports.cloud.mu/g' /etc/apt/sources.list

sudo sed -i 's/ports.ubuntu.com/ubuntu-ports.cloud.mu/g' /etc/apt/sources.list

sudo apt update && apt upgrade

Want to discuss more about Linux mirrors in Mauritius?

The Developers Conference will be held on November 22, 23 and 24 at the Caudan Arts Centre. I will be attending the conference on all three days. There will be plenty of time to meet and discuss about Linux mirrors. Let's grab a coffee there and talk.

A few weeks ago, David Venter of cloud.mu and I were chatting about just that. David gladly provisioned a VM with the specs needed for the mirror. I peeked into some Ubuntu documentation for building the mirror and had a chat on IRC #ubuntu-mirror channel with other mirror admins to understand the disk space requirements.

Once everything was set up, I submitted the mirror for reviewing. That process was not long. In less than 48 hours, the mirror was approved as an official Ubuntu mirror.

I also made an announcement on the Ubuntu mirrors announce list.

At the moment, cloud.mu is the only Ubuntu mirror in Mauritius. About less than a week after submission, the mirror was promoted to country mirror for Mauritius. It means that users do not have to modify their sources.list file to manually add the cloud.mu mirror. During installation, the installer will set the URL for the repo mirror as mu.archive.ubuntu.com. Previously, the sub-domain was pointing to other mirrors. Now, it is now a CNAME for ubuntu-mirror.cloud.mu. Therefore, all requests during Ubuntu updates are sent to the Mauritian mirror.

 <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> @9.9.9.9 mu.archive.ubuntu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48158
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mu.archive.ubuntu.com.		IN	A

;; ANSWER SECTION:
mu.archive.ubuntu.com.	600	IN	CNAME	ubuntu-mirror.cloud.mu.
ubuntu-mirror.cloud.mu.	300	IN	A	102.222.106.237

;; Query time: 552 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Mon Aug 29 10:52:45 +04 2022
;; MSG SIZE  rcvd: 102

The above dig query result shows the CNAME record in place.

Mauritius Internet Exchange Point (MIXP)

The cloud.mu servers benefit from a 10 Gbps link at the Mauritius Internet Exchange Point. All Internet Services Providers that peer at the MIXP, their clients will gain from this low latency Ubuntu mirror.

PING ubuntu-mirror.cloud.mu (102.222.106.237): 56 data bytes
64 bytes from 102.222.106.237: icmp_seq=0 ttl=57 time=5.544 ms
64 bytes from 102.222.106.237: icmp_seq=1 ttl=57 time=9.757 ms
64 bytes from 102.222.106.237: icmp_seq=2 ttl=57 time=6.407 ms
64 bytes from 102.222.106.237: icmp_seq=3 ttl=57 time=8.059 ms
64 bytes from 102.222.106.237: icmp_seq=4 ttl=57 time=9.482 ms

--- ubuntu-mirror.cloud.mu ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.544/7.850/9.757/1.658 ms

What mirrors are available for Ubuntu?

Right now, we have archive and release mirrors. I am hoping that we can have a discussion with more Ubuntu users on the island to see whether we require additional mirrors for Ubuntu security and ports. I am experimenting with Ubuntu 22.04.1 LTS arm64 and will probably set up an update mirror for that.

How to join Ubuntu Mauritius?

Users can join the Ubuntu Mauritius team on Launchpad. The group exists since 2011 but most of the time has remained dormant, with maybe a few Ubuntu Jams organised at the University of Mauritius in the past. If you would like to help with organising regular meetings for the group, ping us via the mailing list: https://lists.launchpad.net/ubuntu-mu.

I was invited to speak at the event and I chose to explain a little about openSUSE, its different distributions and how we have managed to set up two mirrors to improve the performance of openSUSE updates in Mauritius.

Girish is a representative for OSCA Mauritius and he works at OceanDBA. He put all the effort into organising this event. At about 09h30, the conference room at Flying Dodo was almost full. Girish welcomed everyone and introduced the presentation themes for the day.

First presentation – Linux Kernel history by Chittesh Sham

Chittesh is a DevOps Engineer at Corel Corporation. He did a presentation on the Linux Kernel. He tried to summarise three decades of Linux history in one presentation. It was a very informative and fun prez.

Second presentation – Bash Scripting by Shravan Dwarka

Shravan is a Linux System Engineer at OceanDBA. He did a presentation on the Bourne Again SHell (Bash).

After explaining about Shells, Shravan gave a scenario where a database administrator had to automate backups and perform backup retention.

He then explained line by line how he wrote a Bash script to execute the backup.

Final presentation – openSUSE Mirrors in Mauritius

My presentation was last. It's been a while since I set up two openSUSE mirrors in Mauritius. Any openSUSE user on the island will now benefit from fast updates without having to configure anything on their openSUSE machine.

This event was an opportunity to make a public announcement about the mirrors and explain the process behind. That is, how I contacted sponsors for server/bandwidth in Mauritius and got in touch with the openSUSE Heroes to build the repo mirrors.

However, first I did a history lesson about S.u.S.E, SUSE and openSUSE. I clarified that openSUSE is a project and the various distributions have names like Leap, Leap Micro, Tumbleweed and MicroOS.

Then, I showed the tickets that I opened at openSUSE to get the ball rolling. Within a few days we had the mirrors set up.

I mentioned that the domain opensuse.mu is sponsored by the openSUSE project itself. Then, the Heroes created the records to point the domain & sub-domains to servers in Mauritius, sponsored by cloud.mu and Rogers Capital Technology Services.

While speaking about the mirrors, I explained how MirrorBrain works. It is an open source framework to run a content delivery network for mirror servers. The two openSUSE mirrors in Mauritius are mirror.opensuse.mu and mirror.rcts.opensuse.mu. To show how MirrorBrain works with these two servers, I opened get.opensuse.org to download the latest release of openSUSE Leap 15.4.

I selected the offline installation image and we checked the URL from which the image was downloading. It was the Rogers Capital Technology Services (RCTS) mirror server.

I SSH'ed on the cloud.mu mirror server to show how the rsync is done from the restricted rsync server of openSUSE.org. I did not SSH on the RCTS server because it requires a VPN (RCTS engineers take security very seriously 🤓). My VPN setup was on a different machine than the one I was doing my presentation on.

I explained the difference between rsync.opensuse.org and stage.opensuse.org, the former being a public rsync server. It can be used by anyone wishing to run a private openSUSE mirror for home or office use.

The conference room was packed with attendees which is a promising thing for an open source event.

At the end of the event, Joffrey Michaïe, the founder and CEO of OceanDBA addressed the attendees. He thanked the wonderful audience for showing up to the event. Joffrey explained that OceanDBA's business is built on open source technologies and that they have the open source philosophy at the heart of the company.

He was glad to see a lot of young folks attending the event and said that his company would be keen to sponsor such events again in the future. He mentioned that at the moment there are about fifteen open positions at OceanDBA and anyone wishing to apply could reach out to him directly or talk to any other personnel of the company.

The Managing Director of Rogers Capital Technology Services, Dev Hurkoo, and the Roshan Patroo, Manager at RCTS, attended the event. We met after my presentation. They both told me that they were impressed by the attendee turn-out for an open source event. Dev expressed his interest to support open source activities in the future too.

• ZeroSSL CA (default)
• Letsencrypt.org CA
• BuyPass.com CA
• SSL.com CA
• Google.com Public CA
• Pebble strict Mode
• Any other RFC8555-compliant CA

ZeroSSL is the default CA.

In order to request a Let's Encrypt certificate, one can pass the --server letsencrypt directive to change the CA. The default CA can also be changed by issuing:

acme.sh --set-default-ca --server letsencrypt

Let's Encrypt has IPv6 support. However, you can pass --listen-v4 or --listen-v6 to specify whether to use IPv4 or IPv6 to listen.

acme.sh --server letsencrypt --issue --listen-v4 -d sysadmin-journal.com -w /srv/www/sysadmin-journal.com

The above command lets you request a certificate through the Let's Encrypt CA, using the webroot method. In this method, a verification file is created in the webroot path, inside the /.well-know/acme-challenge directory.

Once verification is complete, the file is removed and the certificate, the intermediary certificate and the key are deposited at /etc/letsencrypt/domain_name.

Installation

git clone https://github.com/acmesh-official/acme.sh.git
cd acme.sh

./acme.sh --install -m name@email.com

The above will create the .acme.sh directory in your home directory. Hence, the script will be available as ~./acme.sh/acme.sh. Else, you could also simply clone the project in the /opt directory and create a symlink to the script /usr/local/bin.

Leap is binary compatible with SUSE Linux Enterprise (SLE) as it shares the same source. Therefore, you can switch a Leap instance to SLE and benefit from paid support without any hassle. This comes very handy in environments where you build and test on Leap but deploy on SLE — lift & shift can't be any simpler.

Leap 15.4 is a minor release but coinciding with this release, the openSUSE Project introduced a new version of Leap designed for containers and virtualised workloads. It's called Leap Micro. The current version is 5.2.

Leap Micro shares same source as SLE Micro.

In order to celebrate this release, we organised a virtual openSUSE Beer Party in Mauritius.

Hello everyone! The openSUSE Mauritius community will host a virtual #openSUSE Beer Party TODAY 16h30 — 19h00 to celebrate the Leap 15.4 release. They will do a Leap 15.4 installation live and talk about the openSUSE local mirror. Here is the link to join: https://t.co/D6DpmheC3D pic.twitter.com/SBxiXHrwGA— MSCC (@MSCraftsman) June 10, 2022 Embedded JavaScript

The virtual party was held using the Jitsi Meet platform provided by MIXP. Since it's hosted locally, we expected a smooth quality in video and audio.

Chittesh & Aditya joined the call early on.‌

We're at https://t.co/6oTYOsRycW doing an #openSUSE Leap 15.4 installation & celebrating the recent release. 🍻🥳 pic.twitter.com/AxUuh18Mg1— Ish Sookun (@IshSookun) June 10, 2022 Embedded JavaScript

I had to juggle between doing a few things at home, handling the kid and getting back to call. Sandeep & Nirvan joined us too, and by the end, David joined the call, for the geek chat.

We installed Leap 15.4 in a VM. While chatting with Chittesh & Aditya, I selected the server profile from the installer instead of a GNOME Desktop. Facepalm!

After the installation, I installed patterns-gnome-gnome to have a full blown GNOME Desktop. Sandeep commented downloading of the packages appeared slow. Yes, indeed. So, here I manually switched the repo to mirror.opensuse.mu the ~700 packages downloaded in ~5 mins.

openSUSE Bar

A while later, I joined the openSUSE Bar at meet.opensuse.org/bar. It was nice to have a catch-up with Gertjan after a long time.

Earlier this year, when Luboš Kocman visited Mauritius, we spoke about it again.

Then, a few weeks ago, I heard from cloud.mu, who were willing to sponsor a server for mirror purposes. That was just perfect timing. I had started discussions with an ISP but then cloud.mu was not just willing to provide the server & bandwidth resources but their speed to deploy and assist was even more commendable.

Once the server was ready, the next step was to contact openSUSE admins to update the DNS records for opensuse.mu. I sent my request to the openSUSE Board for the purchase of the domain a long time ago. Until now I used to run a small blog for openSUSE tips & tutorials on opensuse.mu. The domain is owned by SUSE and mananged by the openSUSE admins, i.e the Heroes team.

After a few trials to sync from rsync.opensuse.org and other mirrors closer to Mauritius, I contacted the Heroes to get access to stage.opensuse.org,  the restricted rsync server of openSUSE. Then, it was a matter of a few days to sync all that content.

Finally, the openSUSE mirror for Mauritius was ready.

Compared to other regions, where there are several mirrors in the same country, the whole African continent had only two openSUSE mirrors until now. One managed by TENET (Tertiary Education and Research Network) in South Africa and the other one by Liquid Telecom in Kenya. Mauritius joins that list as the third mirror in the African region, thanks to cloud.mu.

How to switch to the openSUSE Mauritius mirror?

Switching to the Mauritian mirror is easy. First, remove the current repos that you have by either running zypper lr to identify them and zypper rr repo-name to remove the repos, or go to /etc/zypp/repos.d and remove the .repo files of the openSUSE repositories. If you have repos for other applications, e.g Google Chrome, VS Code etc, leave them.

Then, if you're using Leap, you can set up the Leap 15.3 OSS, Non-OSS and Update repositories.

sudo zypper ar https://mirror.opensuse.mu/distribution/leap/15.3/repo/oss openSUSE-Leap-OSS

sudo zypper ar https://mirror.opensuse.mu/distribution/leap/15.3/repo/non-oss openSUSE-Leap-Non-OSS

sudo zypper ar https://mirror.opensuse.mu/update/leap/15.3/oss openSUSE-Leap-Update-OSS

sudo zypper ar https://mirror.opensuse.mu/update/leap/15.3/non-oss openSUSE-Leap-Update-Non-OSS

If you're using Tumbleweed, add the following repositories.

sudo zypper ar https://mirror.opensuse.mu/tumbleweed/repo/oss openSUSE-Tumbleweed-OSS

sudo zypper ar https://mirror.opensuse.mu/tumbleweed/repo/non-oss openSUSE-Tumbleweed-Non-OSS

sudo zypper ar https://mirror.opensuse.mu/update/tumbleweed openSUSE-Tumbleweed-Update-OSS

The mirror contains files for the x86_64 architecture only. If there is a need for other architectures, I'll do the necessary. Ping me on social media or send a mail to ishwon@opensuse.org.

One thing that I noticed was new in the installer is the icon to change the color theme during installation. This was not present when I tested the Leap 15.4 Alpha distribution.

On the top-right corner of the installer there is a moon icon which can be clicked to select a different theme for the installer. Five themes are available which contain three dark and two light variants.

The default theme is set to the installation.qss style sheet.

The cyan-black , highcontrast and white-black are dark themes while installation and style are light themes.

I took the above screenshots using the Leap 15.4 Beta image on VirtualBox to get clear images. In the Twitter thread I took pictures of the installation process and the theme selection on a laptop.

In either installation I did not encounter any bug while setting up GNOME Desktop with defaults.

Nirvan Pagooah, the Secretary of the Linux User Group of Mauritius, made the announcement of the meetup on the LUGM discussion list. Due to sanitary restrictions imposed by the government we could not make the meetup public. We had to keep it a private event with a limited number of attendees.

Luboš told us about some new things that will be coming to Leap in the future. He explained his role as a Release Manager for openSUSE and how the community as a whole is regarded as a SUSE partner. He explained the relationship between SUSE and the openSUSE community. He also talked about SUSE Liberty Linux, a new offering by SUSE which offers support for mixed Linux environment, like RHEL, CentOS and SLES.

Luboš showed us code.opensuse.org/leap/features/issues where community members can request the features they want most in openSUSE Leap. Hence, contributing to making openSUSE distributions better.

I asked whether the feature requests for Leap won't make it such that Leap and Tumbleweed will have different features. Luboš opened opensource.suse.com/legal/policy and explained that the contributions land in Factory first. He talked about the binary compatibility between Leap & SLES and users can test on Leap then migrate to SLES at total ease.

We talked about contributing to open source. Luboš mentioned non-code contributions and how easy it is to contribute to openSUSE. Ajay Ramjatan, one of the founders and the current President of LUGM, mentioned that for many years this is what he's been telling Linux & FOSS enthusiasts, that contributions can be in any form, like designs, translations, etc.

On that note Avinash Meetoo added that the Mauritian Creole (kreol morisien) can be an interesting FOSS project if we would consider adding Kreol support to openSUSE. He mentioned that there are people who are well versed on the topic but might not be techie, that is where we can work together and make it happen.

Renghen Pajanilingum shot a few tech questions, from containers to programming languages & having to compile software using different versions of packages. I know Renghen does not like to spend time fixing the distro problems because he'd rather spend that on actual work. However, he is one of the several Linux people that I have tried to lure to the green side. 😁 Not there yet but I am hopeful that we'll paint his laptop green one day.

I cannot end this blog without thanking Joffrey Michaïe for sponsoring a round of beer 🍺 (and other drinks) for everyone.

At around 5 p.m the meetup ended.

Some of us stayed at Flying Dodo for more beer and to have dinner. Finally, we went to Mugg & Bean for a coffee and continued chatting about work, life and the balance. At 8:30 p.m, the hotel's taxi came for Luboš.

Hoping to be able to meet and greet geekos again.

However, I saw two articles that I would say have misleading titles. One is from betanews.com and the other published by omgubuntu.co.uk. I'm not judging the article authors but I believe the titles should have portrayed the actual Linux Mint announcement.

OMG! Ubuntu! says big changes coming to Firefox on Linux Mint, while the actual changes mean:

• The default start page no longer points to https://www.linuxmint.com/start/
• The default search engines no longer include Linux Mint search partners (Yahoo, DuckDuckGo…) but Mozilla search partners (Google, Amazon, Bing, DuckDuckGo, Ebay…)
• The default configuration switches from Mint defaults to Mozilla defaults.
• Firefox no longer includes code changes or patches from Linux Mint, Debian or Ubuntu.

The above list of changes are the exact ones posted by Clément Lefebvre and let's be honest these do not look like big changes. Anyone not liking the Firefox defaults can still change them to what they prefer and those who had made changes to the Firefox config previously, their preferences will be preserved and not overwritten.

Firefox 96.0 released

Yesterday, Firefox 96.0 was released and in an article, Phoronix talks about the browser's performance. In the same article, the author, Michael Larabel mentioned the Linux Mint/Mozilla partnership announcement without any ambiguity. I quote:

[...] Linux Mint announced on Monday they signed a partnership with Mozilla. Financial details were not disclosed but Linux Mint's Firefox build will be changing its default start page, the default search engines will change to Mozilla search partners, and other modifications for Mozilla.

This election is required to fill two seats on the openSUSE Board, as the term for Simon Lees and Vinzenz Vietzke are coming to an end.

To learn more about openSUSE membership, check out this wiki.

As the initial nominations/applications phase ended, we had only two members who expressed to run for this election. They are:

• Attila Pinter
• Maurizio Galli

Since, we had only two candidates for two available seats, we extended the nominations/applications phase for another two weeks, giving other members the chance to toss the names of people who'd they wish to nominate. However, even after the two weeks, we were still left with only two candidates and therefore, as per the election rule about insufficient nominations, we started the election and each candidate is required to obtain 50% of votes to be considered a winner.

The ballots were opened on the 13th of December and openSUSE members received their voting URL/credentials by email. They can vote until the 30th of December at 23h59 UTC. Ballots will close on 31st December at midnight and a few hours later the result will be announced.