macOS is like a hotel. Everything is polished, designed and cared for. But it’s also sterile and you can’t bring your own furniture or cook your own food. On Linux, you need to do the dishes and take out the trash yourself. But it’s yours. No one forces their agenda on you. It simply feels like home.

Going from macOS to Ubuntu | kvz.io

I received a message on Twitter on 17 October from a fellow who attended the openSUSE Asia Summit 2019. Strangely, I didn't get any notification about it and it's only today that I read the message. He also attended my workshop on openSUSE MicroOS and had some questions regarding inter-Pod communication.

As a quick response, I explained him very breifly about "container networking" and pointed him to the Kubernetes documentation on IP allocation. I do realize though, that most of the times, documenation can be lengthy and {boring}, and that you would just want a simple article or blog post that clears your doubts.

Tell me about Podman networks

Rootless containers (i.e containers started using Podman as a regular user) do not obtain an IP address. Podman uses slirp4netns to allow Internet connectivity inside the container.

Communication with a rootless container is achieved by mapping the container ports to the host, e.g using -p 8080:80 to map a webserver port 80 to the host on port port 8080.

$ podman run -dt --name webserver -p 8080:80 nginx
$ curl http://localhost:8080

Therefore, two rootless containers can communicate over their published ports on the host. Let's experiment this by starting an openSUSE Leap container and installing the telnet package.

$ podman run -dt --name leap leap
$ podman exec -it leap bash

4a0f95e011b9:/ # zypper in telnet

We run ip a s on the host to find its IP address. Say the IP address is 192.168.100.8. Now, from within Leap container let's telnet port 8080 over the host IP.

4a0f95e011b9:/ # telnet 192.168.100.10 8080
Trying 192.168.100.10...
Connected to 192.168.100.10.
Escape character is '^]'.

The connection went through successfully, meaning from the Leap container we've been able to access the Nginx container through it's mapped port on the host.

This same experiment can be repeated using two different pods, say you have a pod that contains your web services and another pod that contains your databases.

$ podman pod create --name webservice -p 8080:80
$ podman run -dt --name webserver --pod webservice nginx

$ podman pod create --name db -p 3306:3306
$ podman run -dt --name mariadb --pod db -e "MYSQL_ALLOW_EMPTY_PASSWORD=yes" mariadb

The Nginx container will be able to reach the MariaDB database over 192.168.100.10:3306 as the same port is mapped on the host.

Ideally, these two containers could have been created in the same pod and therefore share the same network space. Then, the Nginx container would reach the database over localhost:3306 easily.

I used the above Nginx/MariaDB example to explain rootless inter-Pod communication, which was the question that was asked to me initially.

What about rootfull containers?

Rootfull containers are those that are created using Podman with root privileges, either by the root user itself or using sudo privilege.

Containers created using Podman with root privileges obtain an IP address. Podman then uses the Container Network Interfec (CNI) instead of slirp4netns for networking provisioning.

Details about the network subnet is found in the CNI config file.

$ cat /etc/cni/net.d/87-podman-bridge.conflist

{
    "cniVersion": "0.3.0",
    "name": "podman",
    "plugins": [
      {
        "type": "bridge",
        "bridge": "cni0",
        "isGateway": true,
        "ipMasq": true,
        "ipam": {
            "type": "host-local",
            "subnet": "10.88.0.0/16",
            "routes": [
                { "dst": "0.0.0.0/0" }
            ]
        }
      },
      {
        "type": "portmap",
        "capabilities": {
          "portMappings": true
        }
      }
    ]
}

So, let's start a container with root privileges and see.

$ sudo podman run -dt --name db postgres

$ sudo podman inspect -f "{{.NetworkSettings.IPAddress}}" db
10.88.0.30

The podman inspect ... command returns the container's IP address and the same is ranged within the subnet specified in the CNI config. The PostgreSQL database can be accessed over 10.88.0.30:5432 from the host or from within any other container started using root privileges.

$ telnet 10.88.0.30 5432
Trying 10.88.0.30...
Connected to 10.88.0.30.
Escape character is '^]'.

Whatever machine you’re reading this on, it’s highly likely that not all of the CPUs shown by the OS are actually physical processors. That’s because most modern processors use simultaneous multithreading (SMT) to improve performance by executing tasks in parallel.

Intel’s implementation of SMT is known as hyperthreading, and it was originally introduced in 2002 as a way to improve the performance of Pentium 4 and Xeon CPUs that didn’t require increasing the clock frequency. Most Intel CPUs supported the HyperThread Technology (HTT) apart from the Core line of products until the Nehalem microarchitecture which was introduced in 2008. Recently, Intel have announced that they’re moving away from hyperthreading again with their Core product line.

AMD too have dabbled with SMT, and the diagram below shows how SMT works in the Zen microarchitecture.

As the diagram above illustrates, some components are dedicated to each thread and some are shared. Which pieces are shared? That depends on the implementation and can potentially vary with the microarchitecture. But it’s usually some part of the execution unit.

SMT threads usually come in pairs for x86 architecture, and those threads contend with their siblings for access to shared processor hardware. By using SMT you are effectively trying to exploit the natural gaps in a thread’s hardware use. Or as Pekka Enberg eloquently put it:

There are both good and bad reasons to use SMT.

Why is SMT good?

SMT implementations can be very efficient in terms of die size and power consumption, at least when compared with fully duplicating processor resources.

With less than a 5% increase in die size, Intel claims that you can get a 30% performance boost by using SMT for multithreaded workloads.

What you’re likely to see in the real world depends very much on your workload, and like all things performance-related, the only way to know for sure is to benchmark it yourself.

Another reason to favour SMT is that it’s now ubiquitous in modern x86 CPUs. So it’s an easy, achievable way to increase performance. You just need to make sure it’s turned on in your BIOS configuration.

Why is SMT bad?

One of the best and also worst things about SMT is that the operating system doesn’t make it obvious when SMT is enabled. Most of the time, that’s good because it’s an unnecessary distraction. But when it comes to things like capacity planning, or tuning your system for real-time workloads, you really need to know if SMT is enabled.

Take assigning physical CPUs to virtual machines, for example. If you’re not aware that SMT is turned on, it’s easy to think that doubling the number of CPUs will double the performance, but that’s almost certainly not going to be the case if those CPUs are actually SMT siblings because they will be contending for processor resources.

Modern x86 processors come with so many cores (the new AMD Rome CPUs processors have 64 and top-line Intel Core i9 CPUs now have 18) that there’s plenty of performance to be had without enabling SMT.

But perhaps the biggest reason against SMT, and this is definitely the Zeitgeist, is the string of security vulnerabilities that have been disclosed over the last year or so, including L1TF and MDS.

OpenBSD was the first operating system to recommend disabling SMT altogether in August 2018 because they feared that more vulnerabilities would be discovered in this area. They were right.

Greg Kroah Hartman gave a shout out to OpenBSD’s forward thinking in his Open Source Summit talk last month where he said that he had “huge respect” for the project because they made a tough call and chose security over performance.

How to disable SMT

Many users are also now considering disabling SMT all together. Whether or not you’re willing to do that depends on your individual circumstances.

But if you are thinking about it, you’ll need to run benchmarks to understand the performance impact. Which means you’ll need a handy way to run with SMT on and off.

This is usually done in the BIOS setup but if you can’t access it – and if you’re running Linux – you can disable it by writing “off” to the /sys/devices/system/cpu/smt/control file, e.g.

$ nproc
4
$ echo off > /sys/devices/system/cpu/smt/control
$ nproc
2

To re-enable SMT you just need to write “on” to the same file.

So does SMT still make sense? There’s no reason to think that we’ve seen the last of chip-level security vulns, so if you’re at all concerned about security then the safest best is to run with SMT disabled. If you’re concerned about losing performance, you need to get to running those benchmarks.

Instalou o openSUSE Leap 15.1? E agora o que instalar? E os codecs proprietários? Demorou mas foi concluído! O Cool Package é um processo que instala alguns software necessários para a dia a dia de um SUSEIRO e resolver todas as questões de dependências. O Cool Package disponibiliza:

• • Thunderbird
  • Codecs
  • VLC
  • KDEnlive
  • DVDAuthor
  • MPV
  • ffmpeg
  • Lame
  • E outros…

A seguir o botão 1-click Install. que resolver estes questionamentos, pois este botão instala os primeiros softwares principais para a tarefa do dia a dia como: o cliente de email Thunderbird, VLC, MPV, Codecs proprietários e editores de vídeos. Qualquer dúvida, críticas e sugestões em cabelo@opensuse.org

• υποσιτισμό
• μολυσμένο νερό
• παιδική δουλεία
• πορνεία
• πόλεμος
• ελονοσία
• HIV-AIDS
• φυματίωση
• δάγκειος πυρετός
• άλλες παραμελημένες τροπικές ασθένειες

GNU Health εφαρμογή στο νοσοκομείο της Δημόσιας Υγείας του Κράτους της Λάος (CC BY-SA 4.0 GNU Solidario )

GNU Health – Ελευθερία και ισότητα στην υγειονομική περίθαλψη

GNU Solidario πρώτο έργο. Santiago del Estero 2006 . (CC BY-SA 4.0 Luis Falcon)

Παιδιά σε αγροτικό σχολείο του Καμερούν (2018 CC BY-SA 4.0 Luis Falcon)

GNU Health στα Ηνωμένα Έθνη - Διεθνές Ινστιτούτο Παγκόσμιας Υγείας

Le samedi 30 Novembre, 2019, nous organisons notre Journée Mensuelle du Logiciel Libre et de la Cybersécurité à la Maison St Sever à Rouen. (Rez de Chaussée, Centre Commercial St Sever, 10-12 rue Saint-Julien 76100 Rouen) de 14h00 à 18h00. Nous profitons de l’occasion pour communiquer sur les dates du second semestre 2019:Sept 21 De […]

The post #Rouen Journée de la #CyberSécurité et du #Logiciel Libre 30 novembre appeared first on Network Users Institute - Cybersécurité, Intégration de Linux & Logiciels Libres à Rouen, Normandie..