26 Oct 2021

feedFedora People

Justin W. Flory: On Free Software, Red Hat, and Iran

The post On Free Software, Red Hat, and Iran appeared first on Justin W. Flory's blog.

Justin W. Flory's blog - Free & Open Source, travel, and life reflections

I was visiting the Fedora Council ticket tracker when I noticed this ticket up for discussion. The ticket's purpose is minor and appears inconsequential. It involves adding some legal text to the Fedora Accounts system. The change is related to Export Administration Regulations (the "EAR") as maintained by the United States Department of Commerce. And the change is not actually a change, but a clarification of a policy that has always been in effect.

I am opposed to the impact of Export Administration Regulations by the United States as it pertains to free and open source software. I am a strong believer that the impact of these regulations are most harmful to all free & open source software communities at an individual, human level. When I saw this discussion at the Fedora Council level, it offered me an opportunity to reflect on my own feelings about these regulations, and also to share an opinion on how I believe Fedora Linux could truly live up to its certification as a Digital Public Good to ensure a more equitable world.

Here is what I wrote to the Fedora Council, and perhaps also to anyone reading from Red Hat's legal team:

Hi, I would like to add a counter-opinion, of course one that holds no weight as an official vote.

As Fedora Linux is forced to this decision by its relationship to its legal sponsor, Red Hat, I therefore believe it is also the responsibility of Red Hat to seek a solution that does not deny an individual their right to realize the Four Freedoms of Free Software on the basis of geography or citizenship.

I recognize no policy is being changed here. It is a deliberate clarification of rules that were always in effect. Yet this ticket opens the context behind the policy for greater scrutiny, and I posit the context is harmful both to the Fedora Project and to Red Hat.

This policy is harmful for diversity and inclusion, and compromises Fedora's position to be an innovative platform built by a global community. The U.S. laws and regulations driving this decision exist within a specific context, but that context is grossly incompatible with the dynamics of inclusive Free & Open Source communities. In practice, these laws and regulations deny individuals (really, other human beings) of their ability to be a beneficiary of the open licenses we employ for creating our work, collaborating on it together, and sharing it with others.

I see two outcomes of accepting this as an unchangeable norm.

Firstly, it creates confusion, doubt, and feelings of ill intent. These laws and regulations are meant to impact governments and nation-states. In a Free & Open Source community such as ours, these regulations impact individual people. Not governments or nation-states. As an example, a Fedora community member, Ahmad Haghighi, was recently permanently removed from the Fedora Community. In a few quick clicks, Ahmad's legacy in the project was erased. As a precedent, even if someone's contributions were not "supposed" to be accepted in the first place, it does not sit well with me that any one person's legacy of contributions can so easily be removed from project records.

Secondly, it challenges the vision and foundations of the Fedora Project. Particularly our vision statement and the Friends Foundation. When I contribute to the Fedora Project, I do not see people as a citizen of this-country or that-country. I see them as my peers and fellow Fedorans, helping meet that shared vision of creating "a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities." As an American citizen, I know my country makes such discriminations about large groups of people based only on their nationality, but as a contributor to Free & Open Source communities, I see people by their individual character and intention to be a part of our shared vision. But how can we truly aspire to this vision if we are consciously making deliberate exclusions, even if they make little to no sense in our own context? This geographic restriction policy sits in contrast to the vision and purpose we spell out "on paper".

I understand why Fedora leadership is taking this action due to Fedora's legal and sociopolitical relationship to Red Hat, an American incorporation subject to American laws and regulations. To an extent, the hand of Fedora is forced.

But I believe this is a great opportunity for Red Hat to be an enabler of Fedora's First Foundation. Previously, Microsoft stood up for Iranian developers and successfully set a precedent about how the United States Office of Foreign Assets Control (OFAC) treats such cases. I found this excerpt from Nat Friedman's announcement to resonate:

Over the course of two years, we were able to demonstrate how developer use of GitHub advances human progress, international communication, and the enduring US foreign policy of promoting free speech and the free flow of information. We are grateful to OFAC for the engagement which has led to this great result for developers.

Advancing developer freedom: GitHub is fully available in Iran - github.blog

I believe Red Hat's legal team should take a stand for individuals in embargoed countries to remain a beneficiary of the free and open source licenses that enable a community Linux distribution like Fedora to exist in the first place.

After all, in Fedora, we are well-known for being first in the Open Source space for innovative new ideas and approaches. We know Fedora Linux is a digital public good that should be accessible to all and everyone. But to make this a reality, the Fedora Project cannot be first here on its own. We need our friendly primary sponsor, Red Hat, to help us clear this burden, which is brought on by our connection to Red Hat in the first place.

I'll close this counter-opinion with an excerpt from our First Foundation:

"However, the Fedora Project's goal of advancing free software dictates that the Fedora Project itself pursue a strategy that preserves the forward momentum of our technical, collateral, and community-building progress. Fedora always aims to provide the future, first."

From What is Fedora all about?

Here is a chance to be clear on the future we want to provide and for whom.

Background photo by Omid Armin on Unsplash.

26 Oct 2021 9:47pm GMT

Adam Young: What packages are Needed to build the Kernel

In my quest to automate the testing of the Linux Kernel, I need to automate the build of the Linux Kernel. To build the Kernel, you need the requisite packages. What are they? Let's find out.

I am staring with a Baremetal Fedora Image. It has 344 packages installed already. I'm going to assume that this set is available when I do my automated build as well, or that the needed packages will get pulled in by dependencies. If not, I will find out when my automation fails to run and I will add them at that point.

Most Fedora and CentOS based documents on building the Kernel have you do a group install of the "Development Tools" yum package group. I don't want to do this for two reasons. First, I want to use the beaker format which just lists the packages in the job description. Second, I want to minimize the non-required packages, and Development Tools is general purpose group for coding; not everyone needs everythingm, and I don't want to put non-essential packages on the system.

In order to build the linux Kernel, I need to get the code on the server. While I could push it from a remote system, if I want to run this from a beaker job, I will have no machine that can push it. Thus, I will start by installing git.

sudo yum install git

That installs 66 Packages and takes Installed size: 58 MB of space.

Next I clone the Linux kernel tree. I am using https://gitlab.com/linux-kernel/linux, but you can do the same thing from the kernel.org Repo or one of the other public git mirrors. This is quite large and takes a while.

Receiving objects: 100% (8358688/8358688), 1.51 GiB | 20.57 MiB/s, done.

I'm going to use an existing config file to make the old configuration into my new one.

$ make olddefconfig -bash: make: command not found

OK, first missing package. make pulls in libtool-ltdl and guile22

$ make olddefconfig HOSTCC scripts/basic/fixdep /bin/sh: line 1: gcc: command not found make[1]: *** [scripts/Makefile.host:95: scripts/basic/fixdep] Error 127 make: *** [Makefile:552: scripts_basic] Error 2

gcc. No Suprise there. That pulls in 17 packages.

$ make olddefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c /bin/sh: line 1: flex: command not found make[1]: *** [scripts/Makefile.host:9: scripts/kconfig/lexer.lex.c] Error 127 make: *** [Makefile:616: olddefconfig] Error 2

flex also pulls in m4

$ make olddefconfig LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.[ch] /bin/sh: line 1: bison: command not found make[1]: *** [scripts/Makefile.host:17: scripts/kconfig/parser.tab.h] Error 127 make: *** [Makefile:616: olddefconfig] Error 2


That gets through the config build process. Lets checkout the main compile. To speed things up, I compile with 1 thread per CPU:

make -j 32 scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory 25 | #include <openssl>opensslv.h> | ^~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts</openssl>Makefile.host:95: scripts/sign-file] Error 1 make: *** [Makefile:1203: scripts] Error 2

I'm sure there were flamewars about including cryptography in the Linux Kernel. openssl-devel

/bin/sh: line 1: bc: command not found make[1]: *** [Kbuild:24: include/generated/timeconst.h] Error 127 make[1]: *** Waiting for unfinished jobs…. make: *** [Makefile:1219: prepare0] Error 2


main.c:55:10: fatal error: libelf.h: No such file or directory
   55 | #include <libelf.h>
      |          ^~~~~~~~~~

elfutils-libelf-devel. And with that, the make process completes successfully. Lets' now make the modules.

That works, too.

So the minimal list for compile is

26 Oct 2021 9:19pm GMT

Adam Young: bkr job status

Here's a one liner for showing the status of all your beaker jobs.

for JOB in $( bkr job-list -o $( bkr whoami | jq -r '.username' )  | jq -r ".[]"   ) ; do bkr job-results $JOB | xpath -q -e "string(/job/recipeSet/recipe/@status)" ; done

26 Oct 2021 4:39pm GMT

23 Oct 2021

feedFedora People

Jon Chiappetta: Macbook-Pro M1-Max 14 [mega-thread-blog-post]

The beginning of the ARM laptop journey!

<figure class="aligncenter size-large"><figcaption>[Mo. Oct 18. 21]</figcaption></figure>

Custom build-to-order processing:

<figure class="aligncenter size-large"><figcaption>[Sa. Oct 23. 21]</figcaption></figure>

Shipping from a place far far away - AI SHANGHAI, CN.

<figure class="aligncenter size-large"><figcaption>[Mo. Oct 25. 21]</figcaption></figure>

23 Oct 2021 10:01pm GMT

22 Oct 2021

feedFedora People

Adam Young: Remote build of the Linux Kernel via Ironic

Ampere Computing chips run the ARM64 instruction set. My laptop is a Dell running x86_64. In order to edit locally, but build remotely, I make use of servers in our datacenter. These are the steps I am taking.

Prep the machine

First, I create a new server, using Ironic. The following one-liner is the kind of call I can make to create the server instance on a baremetal machine and then add a floating IP address to it.

openstack server create --flavor bm.falcon --image fedora-server-34-aarch64-qcow2 --network baremetal-dataplane --key-name ayoung  f34-kernel-test
openstack server add floating ip f34-kernel-test

Obviously, I have a lot of pre-canned knowledge of the cluster in order to run this command. I know that the flavor bm.falcon will grab one of our falcon instances, and that the image I want for a Fedora 34 server is fedora-server-34-aarch64-qcow2. The following commands let me look up this kind of information:

openstack floating ip list
openstack flavor list
openstack image list
openstack network list
openstack keypair list

The second command adds a floating IP to the server instance. A Floating IP is routable outside of the rack. If I don't add a floating IP, the server will only have link local IP addresses, and the VMs will only be able to talk to each other, and then only if on the same network.

Assuming I am on a machine with the private key that matches the public key identified by the -key-name parameter, I can ssh in to the VM as the fedora User.

ssh fedora@
The authenticity of host ' (' can't be established.
ED25519 key fingerprint is SHA256:sCiBSBv0bmNyBgkprz/TwyY5SI6LmciITNGfUm78wsU.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '' (ED25519) to the list of known hosts.
Failed Units: 1
[fedora@f34-kernel-test ~]$ exit

Once I can get in to the machine interactively, I can use the ssh command to run remote commands. A simple smoke test is to run pwd:

$ ssh fedora@ pwd

Or hostname

$ ssh fedora@ hostname

Send the code

I do not need the entire git repository on the remote machine in order to test it. However, I do want to make sure I check in all my code to some branch to make sure I don't lose it. If I use the git archive command, I can send the source tree over in a stream, and expand it on the remote side.

git archive --format=tar HEAD | ssh fedora@ "mkdir  -p devel/linux && cd devel/linux && tar -x "

The && makes sure that the previous command succeeds before attempting the following command. That keeps you from expanding the contents of the linux directory into your home directory.

Yes, I made that mistake. It is a mess and a pain to clean.

Remote Compile and Install

Here is a pretty clean write up of the set of steps to follow in order to build, install, and run your own kernel.

We can use ssh in order to install the prerequisite packages needed to build the kernel…

ssh fedora@ "sudo dnf install -y kernel-devel kernel-headers bc xz cpio openssl dwarves"
ssh fedora@ sudo dnf group install -y \"Development Tools\"

and to execute the build processes…

ssh fedora@ "cd devel/linux  && make -j 32"
ssh fedora@ "cd devel/linux  && make modules -j 32"

…and to install the kernel…

ssh fedora@ "cd devel/linux  && sudo make install "
ssh fedora@ "cd devel/linux  && sudo make modules_install "

…and to configure the system to boot the kernel.

ssh fedora@ "cd devel/linux  && sudo  grubby --set-default /boot/vmlinuz-5.15.0-rc4"

Confirm that the kernel we want is configured and default:

$ ssh fedora@ "sudo grubby --default-kernel"

Reboot the remote machine and wait for it to come back up.

ssh fedora@ "sudo reboot"

And check the remote status. Note that a change of the Linux Kernel might change the ssh key fingerprint. I had to remove a couple of entries from ~/.ssh/known_hosts.

$ ssh fedora@ "uname -a"
Linux f34-kernel-test.novalocal 5.15.0-rc4 #1 SMP Thu Oct 21 20:07:43 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

These are just my notes for a positive thread, not a recommendation of how to do it. Obviously, the repeated ssh command and parameters should be scripted somehow. Ansible is a likely target. Some of these commands could be put into a script and Some of these commands could be put into a script and executed together as well. What direction we go will in part be directed by the technology we need to perform other tasks, such as queueing and scheduling. Bash is a good starting point, as it is easy to translate to the other technologies.

22 Oct 2021 7:04pm GMT

Adam Young: Shell variable expansion across ssh sessions

ssh allows you to run a command on a remote machine. You may want to use a shell variable in a remote command. You have to be aware of when that variable gets evaluated.

This session started with me interactively logged in on a remote system called f34-kernel-test. We'll call this the server, and the system from which I logged in we'll call the client. My goal is to type the command on the client, hit enter, and see the hostname of the remote system.

[fedora@f34-kernel-test ~]$ echo $HOSTNAME
[fedora@f34-kernel-test ~]$ exit
Connection to closed.
[ayoung@ayoung-home linux]$ echo $HOSTNAME
[ayoung@ayoung-home linux]$ ssh fedora@   echo $HOSTNAME
[ayoung@ayoung-home linux]$ ssh fedora@   "echo $HOSTNAME"
[ayoung@ayoung-home linux]$ ssh fedora@   "echo '$HOSTNAME'"
[ayoung@ayoung-home linux]$ ssh fedora@   "echo \$HOSTNAME"

Note that all of the quoted options failed to prevent the variable expansion from happening on the client system. The only approach which worked here was to escape the slash.

22 Oct 2021 1:40pm GMT

20 Oct 2021

feedFedora People

Bastien Nocera: PSA: gnome-settings-daemon's MediaKeys API is going away

In 2007, Jan Arne Petersen added a D-Bus API to what was still pretty much an import into gnome-control-center of the "acme" utility I wrote to have all the keys on my iBook working.

It switched the code away from remapping keyboard keys to "XF86Audio*", to expecting players to contact the D-Bus daemon and ask to be forwarded key events.

Multimedia keys circa 2003

In 2013, we added support for controlling media players using MPRIS, as another interface. Fast-forward to 2021, and MPRIS support is ubiquitous, whether in free software, proprietary applications or even browsers. So we'll be parting with the "org.gnome.SettingsDaemon.MediaKeys" D-Bus API. If your application still wants to work with older versions of GNOME, it is recommended to at least quiet the MediaKeys API's unavailability.

Multimedia keys in 2021

TL;DR: Remove code that relies on gnome-settings-daemon's MediaKeys API, make sure to add MPRIS support to your app.

20 Oct 2021 12:12pm GMT

19 Oct 2021

feedFedora People

Pablo Iranzo Gómez: LDAP query from Python

Recently, some colleagues commented about validating if users in a Telegram group were or not employees anymore, so that the process could be automated without having to chase down the users that left the company.

One of the fields that can be configured by each user, is the link to other platforms (Github, LinkedIn, Twitter, Telegram, etc), so querying an LDAP server could suffice to get the list of users.

First, we need to get some data required, in our case, we do anonymous binding to our LDAP server and the field to search for containing the 'other platform' links.

We can do a simple query like this in Python:

import ldap

myldap = ldap.initialize("ldap://myldapserver:389")
binddn = ""
pw = ""
basedn = "ou=users,dc=example,dc=com"
searchAttribute = ["SocialURL"]
searchFilter = "(SocialURL=*)"

# this will scope the entire subtree under UserUnits
searchScope = ldap.SCOPE_SUBTREE

# Bind to the server
myldap.protocol_version = ldap.VERSION3
myldap.simple_bind_s(binddn, pw)  # myldap.simple_bind_s() if anonymous binding is desired

# Perform the search
ldap_result_id = myldap.search(basedn, searchScope, searchFilter, searchAttribute)
result_set = []
while True:
    result_type, result_data = myldap.result(ldap_result_id, 0)
    if result_data == []:
        if result_type == ldap.RES_SEARCH_ENTRY:

# Unbind from server

At this point, the variable result_set will contain the values we want to filter, for example, the url containing the username in https://t.me/USERNAMEform and the login id.

This, can be then acted accordingly and kick users that are no longer (or haven't configured Telegram username) in the LDAP directory.


19 Oct 2021 8:34pm GMT

18 Oct 2021

feedFedora People

Jon Chiappetta: Apple M1 Max – Finally Replacing My Last Intel Machine

<figure class="aligncenter size-large"></figure>
<figure class="aligncenter"></figure>

So I've placed an order for my first ARM laptop to finally replace my five year old 2017 Macbook Air (the last Intel processor) - I'm going all-in on ARM !

Machine Specs:

18 Oct 2021 7:24pm GMT

Fedora fans: رنگی کردن خروجی kubectl با kubecolor


kubernetesابزارها و نرم افزارهای گوناگونی جهت تعامل و ارتباط با Kubernetes وجود دارد که یکی از آنها kubectl می باشد که یک ابزار خط فرمانی می باشد. اکنون با استفاده از kubecolor می توان خروجی دستورهای kubectl را به صورت رنگی مشاهده کرد.

روش کار به اینصورت می باشد که kubecolor به صورت داخلی kubectl را فراخوانی می کند (internally calls) و خروجی آن را به صورت رنگی نمایش می دهد و هیچ کار دیگری انجام نمی دهد!

نصب kubecolor:

برای نصب kubecolor کافیست تا به صفحه releases آن در GitHub مراجعه کنید و آخرین نسخه ی آن را برای سیستم عامل خود دانلود کنید:


به عنوان نمونه برای دانلود نسخه x86-64 برای لینوکس کافیست تا دستور زیر را اجرا کنید:

$ wget -c https://github.com/dty1er/kubecolor/releases/download/v0.0.20/kubecolor_0.0.20_Linux_x86_64.tar.gz

سپس آن را از حالت فشرده خارج کنید:

$ tar -xzvf kubecolor_0.0.20_Linux_x86_64.tar.gz

اکنون فایل باینری kubecolor را با استفاده از کاربر root به مسیر زیر منتقل کنید:

# mv kubecolor /usr/local/bin

اکنون برای اجرای خودکار کافیست تا فایل bashrc. خود را باز کنید:

$ vi ~/.bashrc

سپس خطوط زیر را به آن اضافه کنید:

alias kubectl=kubecolor

### autocomplete for kubecolor
complete -o default -F __start_kubectl kubecolor

از این پس هنگام استفاده از دستور kubectl خروجی آن را به صورت رنگی و زیبا مشاهده خواهید کرد. در ادامه تصاویری از کارکرد kubecolor را مشاهده می کنید:



برای اطلاعات بیشتر در مورد kubecolor کافیست تا پروژه آن را بر روی GitHub مشاهده کنید:


The post رنگی کردن خروجی kubectl با kubecolor first appeared on طرفداران فدورا.

18 Oct 2021 7:30am GMT

16 Oct 2021

feedFedora People

Zamir SUN: Setup OpenWRT on BPi-R2

It's pretty easy to get OpenWRT start and running on BPi-R2. However, I realized that I need to extend the root filesystem to the whole disk, which is where the struggling starts.

Setup OpenWRT on BPi-R2

Just download the bpi_bananapi-r2-squashfs-img.gz from openwrt.org and dd it to the TF card like playing with any SBC. Replace sdX with the device name of your card.

$ wget https://downloads.openwrt.org/releases/21.02.0/targets/mediatek/mt7623/openwrt-21.02.0-mediatek-mt7623-bpi_bananapi-r2-squashfs-img.gz
$ sudo dd if=openwrt-21.02.0-mediatek-mt7623-bpi_bananapi-r2-squashfs-img.gz of=/dev/sdX status=progress

Then plug the card into BPi-R2. Make sure the power supply is firmly connected to BPi-R2 (it's a 12v power supply, by the way). Hold the PWR button until the red LED near the power cable lights up, and only the red LED on that area is on. It usually takes 10~15 seconds for me. Release the PWR button now. Soon you'll see the red LED near the power cable goes off and then only the red LED near the GPIO head is on. Now OpenWRT is up and running.

Expand the root partition

This is where the confusion starts. Googling for a while I did not find anything useful. All of a sudden this answer came to my eye and I believe this is the way I should do. In short, the OpenWRT image for BPi-R2 contains 3 partitions. The last partition is not a single partition, but rather, a combination of the squashfs and the f2fs overlay. In order to extend the root partition, we need to extend the f2fs overlay, which requires us to extend the 3rd partition. Here is how I finish it.

root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install losetup

/dev/root /rom squashfs ro,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
/dev/loop0 /overlay f2fs rw,lazytime,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=reuse,fsync_mode=posix 0 0
overlayfs:/overlay / overlay rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
debugfs /sys/kernel/debug debugfs rw,noatime 0 0
none /sys/fs/bpf bpf rw,nosuid,nodev,noexec,noatime,mode=700 0 0

Then check the offset of the f2fs partition

root@OpenWrt:~# losetup
/dev/loop0         0 2883584         1  0 /mmcblk1p3   0     512

Now we see the offset is 2883584 in my case. Remember the number. Power off your BPi-R2 and take out your card. Now we need to connect the card to a running Linux and do the expand.

First let's expand the 3rd partition on the card. I use cfdisk to expand it. You can use any partition tools you are familiar with.

After extending the partition, let's expand the f2fs 'partition' inside. I am using Fedora so I need to install f2fs-tools first. Here we need to use the offset 2883584 we get from the running OpenWRT just now.

$ sudo losetup --show -o 2883584 -f -P /dev/sde3 

Now the partition has been attached to the system as /dev/loop0. Let's try to extend it with resize.f2fs /dev/loop0. In my case, it fails with [f2fs_do_mount:3526] Mount unclean image to replay log first which I think is caused by removing the card when BPi-R2 is still running. Remounting it did not solve my issue. So I just created a brand new f2fs filesystem with

$ sudo mkfs.f2fs -f /dev/loop0

        F2FS-tools: mkfs.f2fs Ver: 1.14.0 (2020-08-24)

Info: Disable heap-based policy
Info: Debug level = 0
Info: Trim is enabled
Info: Segments per section = 1
Info: Sections per zone = 1
Info: sector size = 512
Info: total sectors = 15189504 (7416 MB)
Info: zone aligned segment0 blkaddr: 512
Info: format version with
  "Linux version 5.14.9-200.fc34.x86_64 (mockbuild@bkernel02.iad2.fedoraproject.org) (gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), GNU ld version 2.35.2-5.fc34) #1 SMP Thu Sep 30 11:55:35 UTC 2021"
Info: [/dev/loop0] Discarding device
Info: This device doesn't support BLKSECDISCARD
Info: This device doesn't support BLKDISCARD
Info: Overprovision ratio = 2.330%
Info: Overprovision segments = 176 (GC reserved = 93)
Info: format successful

Detach the loopback device with sudo losetup -D and now it's time to plug the card into BPi-R2 and run again. You'll see your root filesystem is around the size you set by cfdisk.

16 Oct 2021 3:05pm GMT

15 Oct 2021

feedFedora People

Fedora fans: تولد ۲۵ سالگی میزکار KDE


یکی از ویژگی های قابل توجه در دنیای سیستم عامل گنو/لینوکس داشتن میزکارهای (Desktop) گوناگونی می باشد که کاربران بر اساس نیاز و سلیقه ی خود می توانند آنها را انتخاب و استفاده کنند.


یکی از این میزکارها KDE می باشد که هم اکنون تولد ۲۵ سالگی خود را جشن می گیرد. سپاس از تیم توسعه این میزکار زیبا که کار کردن با کامپیوتر را برای کاربران لذت بخش تر کرده است.

شما از چه میزکاری استفاده می کنید؟ تجربه و دیدگاه خود را با ما به اشتراک بگذارید.

The post تولد ۲۵ سالگی میزکار KDE first appeared on طرفداران فدورا.

15 Oct 2021 12:31pm GMT

Adam Young: Ironic Clean PXE failure

One of our ironic baremetal nodes was suffering a cleaing failure. Fixing it was easy…once we knew the cause/

Cleaning is a process by which ironic prepares a node for use. It removes old data and configuration from a node. In order to do that, it has to run a simple image. We use a Debian based image, known as the IPA image, as it runs the Ironic Python Agent. This image is installed via PXE boot. So, if the PXE setup is broken, the node can't be cleaned.

I watched the node boot messagesvia the ipmi Serial over LAN (SOL) console. What I saw was that there indicated "no response from PXE."

The message is specific to the hardware you run.

The PXE server in Ironic matches the node to the the MAC address via the baremetal port.

To find out what the port is foir a given node, use the command like:

openstack baremetal port list  --node ac5bf47b-7185-4db5-ab24-7a396deeaf33

Which shows output like this:

| UUID                                 | Address           |
| 268926f8-eab5-4bdf-8b63-7337da43dd52 | 1c:34:da:5a:c7:b0 |

Then, check the (MAC) address returned with the MAC address reported by PXE. In my case, they did not match. I created a new port with:

 openstack baremetal port create  --node ccad9fe2-1f04-45f1-a4cb-1a993f2a3b69  0c:42:a1:49:ee:c4 

And now port list will show both ports. Delete the old one.

If the node is in the clean wait stage, you can use the following command to get it ready for cleaning:

openstack baremetal node abort ccad9fe2-1f04-45f1-a4cb-1a993f2a3b69

And then restart the cleaning process.

15 Oct 2021 12:13pm GMT

14 Oct 2021

feedFedora People

Máirín Duffy: A new conceptual model for Fedora

<figure aria-describedby="caption-attachment-6254" class="wp-caption alignnone" id="attachment_6254" style="width: 1265px">screenshot of getfedora.org<figcaption class="wp-caption-text" id="caption-attachment-6254">Screenshot of the current getfedora.org website</figcaption></figure>

Fedora's web presence today

It's no news now that Fedora has a new logo, and what you may not realize is that we do not have a new website - when we began the new logo rollout process, we simply updated the logo in-place on our pre-existing website.

The thing is - and this is regardless of the underlying code or framework under-girding the website, which I have no issues with - the messaging and content on the current getfedora.org website has not kept pace with the developments, goals, and general narrative of the Fedora project. We have a lot of different initiatives, developments, and collaborations happening at what I find at times is a dizzying pace that is challenging to keep up with. The number of different fronts that Fedora development takes place on and the low, technical level they occur at makes it difficult to understand the big picture of what exactly Fedora is, and why and how would one want to use it.

As part of the Fedora rebranding project, I've been worrying for a while how we will evolve our web site and our overall web presence. If we're honest, I've been worrying about it quite a bit longer, and some plans we had at making a wildly interactive and participatory community-focused website kind of fell apart some time back and had me feeling somewhat defeated about Fedora's web presence, particularly for contributors. I think some of the recent, rather exciting developments around contributor-focused Fedora assets such as our upcoming new Matrix-based chat server and Discourse-based discussion board (open source platforms!!) have sort of risen from the ashes of that failed initiative and have got me excited to think about Fedora's web presence again.

But what *is* Fedora, exactly? What do I do with it?

This question of what is it and why/how should I use it? is a key message a software project website should have. So in setting out to rethink our website, I set out to answer this question for Fedora in 2021.

Through various conversations with folks around the project over the past few months I discovered that our labyrinthine technical developments and initiatives do in fact feed into a somewhat coherent singular story.

The problem is that our website currently does not tell that story.

In order to tell the story, we need the story. What is it?

Introducing the Fedora "F" Model

A diagram in the shape of an F. We start at the bottom, with a green ball labeled "Desktop User." As we move up the stem of the F (labeled "Development"), there are two branches: (1) an orange "Web/App Developer" branch, and (2) An "IoT Developer" branch. The Web/App developer branch has 3 connected nodes. The first node is labeled, "Local container-based development." The second node is labeled "Container-based development with remote Fedora CoreOS. The third node is labeled "Container-based development on K8S-based runtime." For the IoT developer branch, there are two nodes: "Fedora IoT on device, local container-based development" and "IoT devices at scale" are the labels for those two nodes. To the left of the F-shaped diagram is a circle labeled "quay.io registry" with arrows pointing from the two branches to it (the paths of containers, perhaps.)

Somehow, this diagram oddly turned out to be in the shape of an "F" for Fedora, yay! (It started out as a weird upside-down "L.")

Anyhow, this diagram is meant to represent "the story" of Fedora and how you would use it, and serve as a model from which we will build the narrative for Fedora and its web presence. The core idea here is that there are three different ways of using Fedora, and the hope is that all of these ways (if not currently the default) will someday be the default using container-oriented options. Let's walk through this diagram together and make some sense of it:

Desktop User

We start at the bottom of the "F", at the green node labeled "Desktop User." This is where most people come to Fedora today, and honestly, they need not go anywhere else if this is what they need and what serves them. They come to Fedora looking for a great Linux-based desktop operating system. Ideally, by default, this would be the container-based Silverblue version of Fedora's Desktop - but one thing at a time, I suppose!

This desktop user can just hang out here and have this be their Fedora experience, and that's totally fine. However, if they are interested in building software, or are a developer and looking to migrate to a Linux-based desktop / platform for their development work, they can bridge out from their basic desktop usage, up the spine of the letter "F" and venture into the "Fedora for Development" branches of the F.

Web/App Developer

I struggled to come up with a name for this branch: perhaps you have a better one? The idea here, is these are developers who are writing web apps mostly, kind of a "traditional" web-focused developer who is not developing for specific hardware or IoT style deployment targets (the IoT branch, which we will cover next, is for that.)

We do have users of Fedora today who use Fedora as their main development workstation. Linux as a workstation for developers is an obvious easy sell, since the apps they write are being deployed to UNIX-like environments. What is kind of compelling about Fedora - and sure maybe we could even be better at it with the focus of a narrative like this? - is that we have a lot of built-in tooling to do this type of development in a container-oriented way.

The idea here then is:

IoT Developer

I am not sure if the name for this branch is great either, but it's basically the "Edge Computing" branch… here we have developers using Fedora who intend to deploy to specific hardware of the kind supported by the Fedora IoT Edition.

Here the story starts the same as the previous two - you begin by using Fedora as a Desktop / Workstation. Then you start developing your app using local containers. In this branch, we develop via containers locally on our Fedora Workstation, and in order to test out the code we are writing, we deploy Fedora IoT to the target device and deploy our locally-constructed containers over to Fedora IoT as a container host.

The next step to parallel the Web/App developer branch is to do this IoT, container-based development at scale, deploying to 100's or 1000's+ systems - we don't really have a story for that today, but it's a future end point worth thinking about so I left it in the model.

Containers, Containers, Containers!
An image of Jan from the Brady Bunch

If all of this is being done via the medium of containers - ok, great! Where do those containers live? Where do they go?

I don't know the answer. I drew a "quay.io Registry" bit into the diagram with the idea that anyone can get a free accoutn there and use it to push containers to and pull containers from, as I understand it. I don't know that Fedora wants to be in the business of maintaining its own open container registry (Oh! TIL - we do have one.) But certainly, having a registry somewhere in this narrative would be helpful. So I drew that one in. 🙂

Um, so what does this have to do with the website?

Well, the next step from here is to share this model with all of you fine folks in the Fedora project to see if it makes sense, if anything is missing or needs correction, and to just generally suss out if this is the right story we want to tell about what Fedora is and what you can do with it.

If that works out (my initial bugging a few Fedora folks with this idea seems to indicate it may well work out), then the next step is to construct the content and structure of the Fedora website around this model to make sure the website reflects this model, and to make sure we include all the resources necessary for users of Fedora in order to use it in the way prescribed by this model.

Practically, by way of example, this could mean mention of and support for the usage of the Containers initiative suite of open-source container tooling that we ship in Fedora by default - podman, buildah, cri-o, skopeo, and friends on the Fedora website.

Feedback wanted!

Does this make sense? Is this in need of a lot of work? Does this excite you, or terrify you? Are there corrections to be made, or new ideas you'd like to add?

Your feedback, comments, questions are wholeheartedly encouraged! Let me know in the comments here, or catch me on matrix.org (@duffy:fedora.im.).

14 Oct 2021 9:14pm GMT

13 Oct 2021

feedFedora People

Jon Chiappetta: USB-C – Design by Committee

This is what happens! 😂 ¯\_(ツ)_/¯

<figure class="wp-block-embed aligncenter is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio">

<iframe allowfullscreen="true" class="youtube-player" height="372" sandbox="allow-scripts allow-same-origin allow-popups allow-presentation" src="https://www.youtube.com/embed/8mbaNUm4UD4?version=3&amp;rel=1&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;fs=1&amp;hl=en&amp;autohide=2&amp;wmode=transparent" style="border:0;" width="660"></iframe>


13 Oct 2021 2:59am GMT

12 Oct 2021

feedFedora People

Jon Chiappetta: Having Fun With: DNS Records + Signed Certificates + Cryptographic Algorithms!

So I was experimenting and if you can get signed certs from let's-encrypt and dns records from cloud-flare, then you could store your public signed certificate as a set of split txt entries which anyone could verify with a set of trusted root certificates. You can then use the private key to sign an encryption key (stored as another txt record) along with the encrypted message (also another txt record).

This would allow you to sign, store, and send short messages (in a single direction) with confidentiality, integrity, and authenticity all through a plain text protocol (as long as the root certs exist)!

<figure class="aligncenter size-large"></figure>

Verification Chain:

# ./dns_fun.sh fossjon.com d

        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=R3
            Not Before: Oct  9 18:35:11 2021 GMT
            Not After : Jan  7 18:35:10 2022 GMT
        Subject: CN=*.fossjon.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)


this is just a test of the emergency broadcast system, this is not the real thing!


d="$1" ; z="$2" ; m="$3" ; k="$4"

if [ "$z" == "e" ] ; then
  h=$(echo "$m" | openssl dgst -sha256 -r | awk '{ print $1 }' | tr -d '\t\r\n')

  e=$(echo "$m" | openssl enc -aes-256-cbc -e -k "$t" -S 00 | base64 -b 255)
  echo "$e" ; echo

  s=$(echo -n "$t" | openssl rsautl -sign -inkey privkey.pem | base64 -b 255)
  echo "$s" ; echo

  p=$(cat crt.pem | grep -iv '^---' | base64 -d | base64 -b 255)
  echo "$p" ; echo

if [ "$z" == "d" ] ; then
  c=$(dig "z.pubcrt.$d" txt +short | tr -d ' "\n' | base64 -d | base64 -b 64)
  ( echo '-----BEGIN CERTIFICATE-----' ; echo "$c" ; echo '-----END CERTIFICATE-----' ) > /tmp/crt.pem

  t=$(openssl x509 -text -noout -in /tmp/crt.pem | grep -i 'exponent' -B 64)
  echo "$t" ; echo

  v=$(dig "z.pubkey.$d" txt +short | tr -d ' "\n' | base64 -d | openssl rsautl -verify -certin -inkey /tmp/crt.pem)
  echo "$v" ; echo

  o=$(dig "z.pubmsg.$d" txt +short | tr -d ' "\n' | base64 -d | openssl enc -aes-256-cbc -d -k "$v")
  echo "$o" ; echo

12 Oct 2021 4:53am GMT