fidzu : Fedora

I am pleased to announce a new release 2.0 of Entangle is available for download from the usual location:

  https://entangle-photo.org/download/

This release is largely bug fixes with a couple of small features

• Require gobject introspection >= 1.54
• Require GTK3 >= 3.22
• Fix dependency on libraw
• Fix variable name in photobox plugin
• Document some missing keyboard shortcuts
• Fix upper bound in histogram to display clipped pixel
• Refresh translations
• Option to highlight over exposed pixels in red
• Disable noisy compiler warning
• Remove use of deprecated application menu concept
• Fix image redraw when changing some settings
• Update mailing list address in appdaat
• Add more fields to appdata content
• Fix refrence counting during window close
• Use correct API for destroying top level windows
• Fix unmounting of cameras with newer gvfs URI naming scheme
• Avoid out of bounds read of property values
• Fix many memory leaks
• Workaround for combo boxes not displaying on Wayland
• Fix race condition in building enums
• Fix setting of gschema directory during startup
• Set env to ensure plugins can find introspection typelib Requires

16 Jan 2019 9:44pm GMT

Epylog is a log analysis code written by Konstantin ("Icon") Ryabitsev, when he was working Duke University in the early 2000's. It was moved to FedoraHosted and then never got moved to other hosting afterwords. The code is written in early python2 syntax (maybe 2.2) and has been hacked to work with newer versions over time but has not seen any major development since 2008. I have been sort of looking after the package in Fedora with the hopes of a 'rewrite for Python3' that never got done by me. [This is on me as I have been licking the cookie here.]

Because it requires a lot of work, and Python 2's End of Life is coming up in a year, I retired it from rawhide so that it would not branch to Fedora 30. I would recommend that users of epylog look for newer replacements (we in Fedora infrastructure will be doing so and I will post any recommendations as time goes by).

16 Jan 2019 7:44pm GMT

Aide es un sistema avanzado de detección de intrusión que nos permite visualizar cambios en los archivos. Si una persona accede de forma ilegal a nuestro servidor y modifica un archivo que no tiene que tocar, este sistema de intrusión te lo detecta mediante el hash del archivo.

También permite revisar nuevos archivos creados, eliminados o modificados. Al realizar un escaneo a los archivos puede devolver diversos códigos de salida como errores de escritura, argumentos inválidos, funciones incom...

16 Jan 2019 7:20pm GMT

The Fedora Respins SIG is pleased to announce the latest release of Updated F29-20190115 Live ISOs, carrying the 4.19.14-300 kernel.

This set of updated isos will save considerable amounts of updates after install. ((for new installs.)(New installs of Workstation have 1.2GB of updates).

This Set also includes a One-Off Build of the Security Lab.

16 Jan 2019 6:30pm GMT

Fedora Classroom sessions continue with an introductory session on Fedora Localization (L10N). The general schedule for sessions is available on the wiki, along with resources and recordings from previous sessions. Read on for more details about the upcoming L10N Classroom session next week.

Topic: Getting Started with L10N

The goal of the Fedora Localization Project (FLP) is to bring everything around Fedora (the Software, Documentation, Websites, and culture) closer to local communities (countries, languages and in general cultural groups). The session is aimed at beginners. Here is the agenda:

• What is L10N?
• Difference between Translation and Localization
• Overview: How does L10N work?
• Fedora structure and peculiarities related to L10N
• Ways to join, help, and contribute
• Further information with references and links

When and where

• This session will be streamed live on the Fedora YouTube channel.
• It will be held on Monday, 21st January 2019 at 1200 UTC. (Please click the link to see the time in your local time zone).

Instructor

Silvia Sánchez has been a Fedora community member for a number of years. She currently focuses her contributions on QA, translation, wiki editing, and the Ambassadors teams among others. She has a varied background, having studied systems, programming, design, and photography. She speaks, reads, and writes Spanish, English, and German and further, also reads Portuguese, French, and Italian. In her free time, Silvia enjoys forest walks, art, and writing fiction.

16 Jan 2019 8:00am GMT

Hace unos días acabé una pequeña herramienta Web llamada Share Your Doc, que permite compartir código fuente, mensajes, scripts...etc via Web como si fuese un típico servicio de Pastebin, Fpaste como seguramente conocerás.

Sin embargo, lo bueno que tiene este, es que trabaja conjuntamente con el sistema operativo, no requiere de ningún método para validarse de usuarios, ni tampoco hace uso de conexiones FTP. Simplemente, añades tu código, creas el token y a correr.

Es una herramienta...

15 Jan 2019 7:40pm GMT

As CES draws to a close, I've seen more than one security person complain that nobody at the show was talking about security. There were an incredible number of consumer devices unveiled, no doubt there is no security in any of them. I think we get caught up in the security world sometimes so we forget that the VAST majority of people don't care if something has zero security. People want interesting features that amuse them or make their lives easier. Security is rarely either of these, generally it makes their lives worse so it's an anti-feature to many.

Now the first thing many security people think goes something like this "if there's no security they'll be sorry when their lightbulb steals their wallet and dumps the milk on the floor!!!" The reality is that argument will convince nobody, it's not even very funny so they're laughing at us, not with us. Our thoughts by very nature blame all the wrong people and we try to scare them into listening to us. It's never worked. Ever. That one time you think it worked they were only pretended to care so you would go away.

So it brings us to the idea that security isn't a feature. Turning your lights on is a feature. Cooking you dinner is a feature. Driving your car is a feature. Not bursting into flames is not a feature. Well it sort of is, but nobody talks about it. Security is a lot like the bursting into flames thing. Security really is about something not happening, things not happening is the fundamental problem we have when we try to talk about all this. You can't build a plausible story around an event that may or may not happen. Trying to build a narrative around something that may or may not happen is incredibly confusing. This isn't how feature work, features do positive things, they don't not do negative things (I don't even know if that's right). Security isn't a feature.

So the question you should be asking then is how do we make products being created contain more of this thing we keep calling security. The reality is we can't make this happen given our current strategies. There are two ways products will be produced that are less insecure (see what I did there). Either the market demands it, which given the current trends isn't happening anytime soon. People just don't care about security. The second way is a government creates regulations that demand it. Given the current state of the world's governments, I'm not confident that will happen either.

Let's look at market demand first. If consumers decide that buying products that are horribly insecure is bad, they could start buying products with more built in security. But even the security industry can't define what that really means. How can you measure which product has the best security? Consumers don't have a way to know which products are safer. How to measure security could be a multi-year blog series so I won't get into the details today.

What if the government regulates security? We sort of end up in a similar place to consumer demand. How do we define security? It's a bit like defining safety I suppose. We're a hundred years into safety regulations and still get a lot wrong and I don't think anyone would argue defining safety is much easier than defining security. Security regulation would probably follow a similar path. It will be decades before things could be good enough to create real change. It's very possible by then the machines will have taken over (that's the secret third way security gets fixed, perhaps a post for another day).

So here we are again, things seem a bit doom and gloom. That's not the intention of this post. The real purpose is to point out we have to change the way we talk about security. Yelling at vendors for building insecure devices isn't going to ever work. We could possibly talk to consumers in a way that resonates with them, but does anyone buy the stove that promises to burst into flames the least? Nobody would ever use that as a marketing strategy. I bet it would have the opposite effect, a bit like our current behaviors and talking points I suppose.

Complaining that companies don't take security seriously hasn't ever worked and never will work. They need an incentive to care, us complaining isn't an incentive. Stay tuned for some ideas on how to frame these conversations and who the audience needs to be.

15 Jan 2019 3:48pm GMT

Riječka podružnica Hrvatske udruge Linux korisnika i Odjel za informatiku Sveučilišta u Rijeci pozivaju vas na OpenClass koji će se održati četvrtak, 17. siječnja 2019. u 17 sati, u zgradi Sveučilišnih odjela, prostorija O-028. Naslov:

Kontinuirana integracija i isporuka u razvoju softvera

Predavač je Kristijan Lenković, bivši student Odjela za informatiku i voditelj softverskog razvojnog tima u tvrtci Coadria/iOLAP u Rijeci.

Sažetak

Razgovarat će se o kontinuiranoj integraciji i isporuci kao dijelu životnog ciklusa razvoja modernog softvera, a poseban naglasak bit će stavljen na razvoj web aplikacija. Cilj ove metodologije je stabilan, učinkovit, siguran i brz razvoj s prethodno definiranom infrastrukturom i okruženjem na kojem će se aplikacija pokretati te značajno smanjenje visokih troškova, vremena i rizika prilikom isporuke softvera na produkcijsko okruženje.

Nadamo se vašem dolasku!

15 Jan 2019 12:44pm GMT

The kernel team is working on final integration for kernel 4.20. This version was just recently released, and will arrive soon in Fedora. This version has many security fixes included. As a result, the Fedora kernel and QA teams have organized a test day for Tuesday, January 15, 2019. Refer to the wiki page for links to the test images you'll need to participate.

How do test days work?

A test day is an event where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you've never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to do the following things:

• Download test materials, which include some large files
• Read and follow directions step by step

The wiki page for the kernel test day has a lot of good information on what and how to test. After you've done some testing, you can log your results in the test day web application. If you're available on or around the day of the event, please do some testing and report your results.

Happy testing, and we hope to see you on test day.

14 Jan 2019 6:49pm GMT

One thing that I noticed as I got settled in to this role last summer is that the Fedora release schedule tasks look a lot like they did when I first started contributing almost a decade ago. That's not necessarily a bad thing - if it's not broke, don't fix it. but I suspect it's less because we're still getting releases out in the same way we did 10 years ago and more because we haven't captured when reality has drifted from the schedule.

As I start putting together a draft of the Fedora 31 release schedule, I want to take the opportunity to re-converge on reality. Last week, I sent an email to all of the teams that have a schedule in the main release schedule requesting updates to the tasks they have.

I'm putting the question to the larger community now. What tasks should be added, changed, or removed from the schedules? Are there teams that should be specifically called out in the release schedule? How can our release schedules better serve the community? I'm open to your feedback via email or as an issue on the schedule Pagure repo.

The post Updating release schedule tasks appeared first on Fedora Community Blog.

14 Jan 2019 4:03pm GMT

I've been thinking about to automating my living for quite some time. Basically, my requirements are:

• I can control the power of some home appliances no matter which platform I am using, be it Linux or Android or even iOS. And it can be controlled with customized rules.
• I can power on my workstation without using WOL.

For the first requirement I've purchased some so-called smart power strip in the early days. But unfortunately it has a lot of limitations and they are not really 'smart'. Most of them only work with a timer. So I've been looking for alternatives.

Well for the second requirement, I've been thinking about adding a relay to control the power button. However after some discussion with Shankerwangmiao and z4yx, they told me they already have made some product level prototype, and Shankerwangmiao kindly offered me the PCIe adapter they made for free. They call it IPMI_TU.

During the new year holiday, I decide to spend more time into the first requirement. And Sonoff comes up to me. Their products use an app called EWeLink which seems to have more features than the ones I have. After some research, I know Sonoff products are equipped with a SoC called ESP8266, which is very popular recently in the so-called 'IoT' area. I even found an open source firmware for a series of Sonoff products called Sonoff Tasmota which is appealing to me. The Sonoff Tasmota firmware supports controlling using MQTT, which is a plus as I can make customized rules anywhere and just make the MQTT call when the rules met. The Sonoff Tasmota firmware also works on many other ESP8266 based smart plug, so I checked their list and finally come up with one of the smaller sized variant and a Sonoff Basic smart switch to control my light.

Now it's the time to flash them. I think it is easy, but in fact, it really takes me some time.

In order to learn about the Arduino IDE and ESP8266 flashing, I purchased a NodeMCU board in advance. The Arduino IDE is available in Fedora so I only need to do dnf install -y arduino. But this is just the beginning. To make a long story short, I need to install a bunch of Arduino libraries which is not a problem first, but result in I need to choose some older version library to workaround bugs in newer ones.

So here are some notes when I try to flash the Huafan smart plug I purchased.

• Crystal Frequency needs to be changed to 40MHz
• Choose v1.4 Prebuild for IwIP Variant to workaround some bug
• Always connect GPIO0 to ground before power the ESP8266 on for flashing. It can be disconnected after powering up, but it won't work if you power the ESP8266 on then connect GPIO0.

The first is pretty straight forward, but the other 2 notes really took me a long debugging time before I know the expected way.

Thanks for imi415's suggestions on narrowing the WiFi problem down.

And for flashing the Sonoff Basic switch:

• Remember to change Crystal Frequency back to 26MHz
• The IwIP Variant still need to be v1.4 Prebuild
• Disable some unessential features if you don't need by editing my_user_config.h

That's pretty much of it for the two.

Then it comes to the IPMI_TU. IPMI_TU is not ESP8266 based. Instead, they use STM32F103 which is an ARM Cortex-M3 MCU, and a WIZnet W5500 ethernet controller. To flash an STM32 a tool called stlink is needed, which is also available in Fedora as stlink or stlink-gui.

Since IPMI_TU originally designed for other use cases, they use Protocol Buffers as the data serialization protocol in their firmware. This is overkill for my use case, so I replaced the control function with a plain text one.

When it comes to flashing, I did something wrong in the beginning, and after that, I cannot flash it again using the open source variant of stlink. I figured out a way to re-flash its bootloader and used the official STM32 flashing tool to flash. Luckily after that, the STM32 is back to normal.

One more thing to note, the firmware of IPMI_TU uses the DHCP log server option as a hackerish way determine the MQTT, so changes to the DHCP configuration is needed.

Now the firmware part is done. I'll write my experience about the server side later on.

14 Jan 2019 2:29pm GMT

Official web site: NGINX Unit

The official repository, for RHEL and CentOS, provides the PHP module PHP version (5.3 / 5.4) in official repository.

My repository provides various versions of the module, as base packages (unit-php) and as Software Collections (php##-unit-php).

Here is small test tutorial, to create 1 application per available PHP version.

1. Official repository installation

For now, the packages are only available for CentOS / RHEL 6 and 7.

Create the repository configuration, read CentOS Packages in official documentation.

[unit]
name=unit repo
baseurl=https://packages.nginx.org/unit/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Edite: the main unit package is now also available in my repository, so the official upstream repository is no more mandatory. It includes changes from PR #212 et #215 under review.

2. Remi repository installation

# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
# yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm

3. Server and modules installation

Install theNGINX unit server and various PHP modules. The unit-php package provides the module for the system default php.

# yum install unit unit-php php56-unit-php php71-unit-php php72-unit-php php73-unit-php

4. Test configuration

4.1 Preparation

This configuration create a listener for each PHP version,listening on a different port(8300, 8356, ...) and an application serving the usual web application directory.

Download the unit.config file:

{
        "applications": {
                "exphp": {
                        "type": "php",
                        "user": "nobody",
                        "processes": 2,
                        "root": "/var/www/html",
                        "index": "index.php"
                },
                "exphp56": {
                        "type": "php 5.6",
                        "user": "nobody",
                        "processes": 2,
                        "root": "/var/www/html",
                        "index": "index.php"
                },
                "exphp71": {
                        "type": "php 7.1",
                        "user": "nobody",
                        "processes": 2,
                        "root": "/var/www/html",
                        "index": "index.php"
                },
                "exphp72": {
                        "type": "php 7.2",
                        "user": "nobody",
                        "processes": 2,
                        "root": "/var/www/html",
                        "index": "index.php"
                },
                "exphp73": {
                        "type": "php 7.3",
                        "user": "nobody",
                        "processes": 2,
                        "root": "/var/www/html",
                        "index": "index.php"
                }
        },
        "listeners": {
                "*:8300": {
                        "application": "exphp"
                },
                "*:8356": {
                        "application": "exphp56"
                },
                "*:8371": {
                        "application": "exphp71"
                },
                "*:8372": {
                        "application": "exphp72"
                },
                "*:8373": {
                        "application": "exphp73"
                }
        }
}

4.2 Run the service:

# systemctl start unit

4.3 Configuration

Configuration is managed through a REST API:

# curl -X PUT --data-binary @unit.config --unix-socket /var/run/unit/control.sock http://localhost/config
{
    "success": "Reconfiguration done."
}

And to check running configuration:

# curl --unix-socket /var/run/unit/control.sock http://localhost/config

5 Usage

You can access the application on each new port:

• http://localhost:8300/ for default PHP
• http://localhost:8356/ for PHP version 5.6
• http://localhost:8372/ for PHP version 7.2
• etc

The phpinfo page will display language informations, to be noticed, in this case, Serveur API is unit.

6. Conclusion

As this is a application server, we'll probably plug it behing a web frontal (Apache HHTP server or NGINX).

This project seems interesting, but is quite young (the first version 1.2 available on github was released on june 2018); will see what the user feedback will be.

Current version is 1.7.

Edited: I think that this tool is particularly interesting to manage various languages and various version, so ideal with Software Collections.

14 Jan 2019 2:21pm GMT

One significant limitation of the netboot server built in this series is the operating system image being served is read-only. Some use cases may require the end user to modify the image. For example, an instructor may want to have the students install and configure software packages like MariaDB and Node.js as part of their course walk-through.

An added benefit of writable netboot images is the end user's "personalized" operating system can follow them to different workstations they may use at later times.

Change the Bootmenu Application to use HTTPS

Create a self-signed certificate for the bootmenu application:

$ sudo -i
# MY_NAME=$(</etc/hostname)
# MY_TLSD=/opt/bootmenu/tls
# mkdir $MY_TLSD
# openssl req -newkey rsa:2048 -nodes -keyout $MY_TLSD/$MY_NAME.key -x509 -days 3650 -out $MY_TLSD/$MY_NAME.pem

Verify your certificate's values. Make sure the "CN" value in the "Subject" line matches the DNS name that your iPXE clients use to connect to your bootmenu server:

# openssl x509 -text -noout -in $MY_TLSD/$MY_NAME.pem

Next, update the bootmenu application's listen directive to use the HTTPS port and the newly created certificate and key:

# sed -i "s#listen => .*#listen => ['https://$MY_NAME:443?cert=$MY_TLSD/$MY_NAME.pem\&key=$MY_TLSD/$MY_NAME.key\&ciphers=AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA'],#" /opt/bootmenu/bootmenu.conf

Note the ciphers have been restricted to those currently supported by iPXE.

GnuTLS requires the "CAP_DAC_READ_SEARCH" capability, so add it to the bootmenu application's systemd service:

# sed -i '/^AmbientCapabilities=/ s/$/ CAP_DAC_READ_SEARCH/' /etc/systemd/system/bootmenu.service
# sed -i 's/Serves iPXE Menus over HTTP/Serves iPXE Menus over HTTPS/' /etc/systemd/system/bootmenu.service
# systemctl daemon-reload

Now, add an exception for the bootmenu service to the firewall and restart the service:

# MY_SUBNET=192.0.2.0
# MY_PREFIX=24
# firewall-cmd --add-rich-rule="rule family='ipv4' source address='$MY_SUBNET/$MY_PREFIX' service name='https' accept"
# firewall-cmd --runtime-to-permanent
# systemctl restart bootmenu.service

Use wget to verify it's working:

$ MY_NAME=server-01.example.edu
$ MY_TLSD=/opt/bootmenu/tls
$ wget -q --ca-certificate=$MY_TLSD/$MY_NAME.pem -O - https://$MY_NAME/menu

Add HTTPS to iPXE

Update init.ipxe to use HTTPS. Then recompile the ipxe bootloader with options to embed and trust the self-signed certificate you created for the bootmenu application:

$ echo '#define DOWNLOAD_PROTO_HTTPS' >> $HOME/ipxe/src/config/local/general.h
$ sed -i 's/^chain http:/chain https:/' $HOME/ipxe/init.ipxe
$ cp $MY_TLSD/$MY_NAME.pem $HOME/ipxe
$ cd $HOME/ipxe/src
$ make clean
$ make bin-x86_64-efi/ipxe.efi EMBED=../init.ipxe CERT="../$MY_NAME.pem" TRUST="../$MY_NAME.pem"

You can now copy the HTTPS-enabled iPXE bootloader out to your clients and test that everything is working correctly:

$ cp $HOME/ipxe/src/bin-x86_64-efi/ipxe.efi $HOME/esp/efi/boot/bootx64.efi

Add User Authentication to Mojolicious

Create a PAM service definition for the bootmenu application:

# dnf install -y pam_krb5
# echo 'auth required pam_krb5.so' > /etc/pam.d/bootmenu

Add a library to the bootmenu application that uses the Authen-PAM perl module to perform user authentication:

# dnf install -y perl-Authen-PAM;
# MY_MOJO=/opt/bootmenu
# mkdir $MY_MOJO/lib
# cat << 'END' > $MY_MOJO/lib/PAM.pm
package PAM;

use Authen::PAM;

sub auth {
   my $success = 0;

   my $username = shift;
   my $password = shift;

   my $callback = sub {
      my @res;
      while (@_) {
         my $code = shift;
         my $msg = shift;
         my $ans = "";
   
         $ans = $username if ($code == PAM_PROMPT_ECHO_ON());
         $ans = $password if ($code == PAM_PROMPT_ECHO_OFF());
   
         push @res, (PAM_SUCCESS(), $ans);
      }
      push @res, PAM_SUCCESS();

      return @res;
   };

   my $pamh = new Authen::PAM('bootmenu', $username, $callback);

   {
      last unless ref $pamh;
      last unless $pamh->pam_authenticate() == PAM_SUCCESS;
      $success = 1;
   }

   return $success;
}

return 1;
END

The above code is taken almost verbatim from the Authen::PAM::FAQ man page.

Redefine the bootmenu application so it returns a netboot template only if a valid username and password are supplied:

# cat << 'END' > $MY_MOJO/bootmenu.pl
#!/usr/bin/env perl

use lib 'lib';

use PAM;
use Mojolicious::Lite;
use Mojolicious::Plugins;
use Mojo::Util ('url_unescape');

plugin 'Config';

get '/menu';
get '/boot' => sub {
   my $c = shift;

   my $instance = $c->param('instance');
   my $username = $c->param('username');
   my $password = $c->param('password');

   my $template = 'menu';

   {
      last unless $instance =~ /^fc[[:digit:]]{2}$/;
      last unless $username =~ /^[[:alnum:]]+$/;
      last unless PAM::auth($username, url_unescape($password));
      $template = $instance;
   }

   return $c->render(template => $template);
};

app->start;
END

The bootmenu application now looks for the lib directory relative to its WorkingDirectory. However, by default the working directory is set to the root directory of the server for systemd units. Therefore, you must update the systemd unit to set WorkingDirectory to the root of the bootmenu application instead:

# sed -i "/^RuntimeDirectory=/ a WorkingDirectory=$MY_MOJO" /etc/systemd/system/bootmenu.service
# systemctl daemon-reload

Update the templates to work with the redefined bootmenu application:

# cd $MY_MOJO/templates
# MY_BOOTMENU_SERVER=$(</etc/hostname)
# MY_FEDORA_RELEASES="28 29"
# for i in $MY_FEDORA_RELEASES; do echo '#!ipxe' > fc$i.html.ep; grep "^kernel\|initrd" menu.html.ep | grep "fc$i" >> fc$i.html.ep; echo "boot || chain https://$MY_BOOTMENU_SERVER/menu" >> fc$i.html.ep; sed -i "/^:f$i$/,/^boot /c :f$i\nlogin\nchain https://$MY_BOOTMENU_SERVER/boot?instance=fc$i\&username=\${username}\&password=\${password:uristring} || goto failed" menu.html.ep; done

The result of the last command above should be three files similar to the following:

menu.html.ep:

#!ipxe

set timeout 5000

:menu
menu iPXE Boot Menu
item --key 1 lcl 1. Microsoft Windows 10
item --key 2 f29 2. RedHat Fedora 29
item --key 3 f28 3. RedHat Fedora 28
choose --timeout ${timeout} --default lcl selected || goto shell
set timeout 0
goto ${selected}

:failed
echo boot failed, dropping to shell...
goto shell

:shell
echo type 'exit' to get the back to the menu
set timeout 0
shell
goto menu

:lcl
exit

:f29
login
chain https://server-01.example.edu/boot?instance=fc29&username=${username}&password=${password:uristring} || goto failed

:f28
login
chain https://server-01.example.edu/boot?instance=fc28&username=${username}&password=${password:uristring} || goto failed

fc29.html.ep:

#!ipxe
kernel --name kernel.efi ${prefix}/vmlinuz-4.19.5-300.fc29.x86_64 initrd=initrd.img ro ip=dhcp rd.peerdns=0 nameserver=192.0.2.91 nameserver=192.0.2.92 root=/dev/disk/by-path/ip-192.0.2.158:3260-iscsi-iqn.edu.example.server-01:fc29-lun-1 netroot=iscsi:192.0.2.158::::iqn.edu.example.server-01:fc29 console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet
initrd --name initrd.img ${prefix}/initramfs-4.19.5-300.fc29.x86_64.img
boot || chain https://server-01.example.edu/menu

fc28.html.ep:

#!ipxe
kernel --name kernel.efi ${prefix}/vmlinuz-4.19.3-200.fc28.x86_64 initrd=initrd.img ro ip=dhcp rd.peerdns=0 nameserver=192.0.2.91 nameserver=192.0.2.92 root=/dev/disk/by-path/ip-192.0.2.158:3260-iscsi-iqn.edu.example.server-01:fc28-lun-1 netroot=iscsi:192.0.2.158::::iqn.edu.example.server-01:fc28 console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet
initrd --name initrd.img ${prefix}/initramfs-4.19.3-200.fc28.x86_64.img
boot || chain https://server-01.example.edu/menu

Now, restart the bootmenu application and verify authentication is working:

# systemctl restart bootmenu.service

Make the iSCSI Target Writeable

Now that user authentication works through iPXE, you can create per-user, writeable overlays on top of the read-only image on demand when users connect. Using a copy-on-write overlay has three advantages over simply copying the original image file for each user:

1. The copy can be created very quickly. This allows creation on-demand.
2. The copy does not increase the disk usage on the server. Only what the user writes to their personal copy of the image is stored in addition to the original image.
3. Since most sectors for each copy are the same sectors on the server's storage, they'll likely already be loaded in RAM when subsequent users access their copies of the operating system. This improves the server's performance because RAM is faster than disk I/O.

One potential pitfall of using copy-on-write is that once overlays are created, the images on which they are overlayed must not be changed. If they are changed, all the overlays will be corrupted. Then the overlays must be deleted and replaced with new, blank overlays. Even simply mounting the image file in read-write mode can cause sufficient filesystem updates to corrupt the overlays.

Due to the potential for the overlays to be corrupted if the original image is modified, mark the original image as immutable by running:

# chattr +i </path/to/file>

You can use lsattr </path/to/file> to view the status of the immutable flag and use to chattr -i </path/to/file> unset the immutable flag. While the immutable flag is set, even the root user or a system process running as root cannot modify or delete the file.

Begin by stopping the tgtd.service so you can change the image files:

# systemctl stop tgtd.service

It's normal for this command to take a minute or so to stop when there are connections still open.

Now, remove the read-only iSCSI export. Then update the readonly-root configuration file in the template so the image is no longer read-only:

# MY_FC=fc29
# rm -f /etc/tgt/conf.d/$MY_FC.conf
# TEMP_MNT=$(mktemp -d)
# mount /$MY_FC.img $TEMP_MNT
# sed -i 's/^READONLY=yes$/READONLY=no/' $TEMP_MNT/etc/sysconfig/readonly-root
# sed -i 's/^Storage=volatile$/#Storage=auto/' $TEMP_MNT/etc/systemd/journald.conf
# umount $TEMP_MNT

Journald was changed from logging to volatile memory back to its default (log to disk if /var/log/journal exists) because a user reported his clients would freeze with an out-of-memory error due to an application generating excessive system logs. The downside to setting logging to disk is that extra write traffic is generated by the clients, and might burden your netboot server with unnecessary I/O. You should decide which option - log to memory or log to disk - is preferable depending on your environment.

Since you won't make any further changes to the template image, set the immutable flag on it and restart the tgtd.service:

# chattr +i /$MY_FC.img
# systemctl start tgtd.service

Now, update the bootmenu application:

# cat << 'END' > $MY_MOJO/bootmenu.pl
#!/usr/bin/env perl

use lib 'lib';

use PAM;
use Mojolicious::Lite;
use Mojolicious::Plugins;
use Mojo::Util ('url_unescape');

plugin 'Config';

get '/menu';
get '/boot' => sub {
   my $c = shift;

   my $instance = $c->param('instance');
   my $username = $c->param('username');
   my $password = $c->param('password');

   my $chapscrt;
   my $template = 'menu';

   {
      last unless $instance =~ /^fc[[:digit:]]{2}$/;
      last unless $username =~ /^[[:alnum:]]+$/;
      last unless PAM::auth($username, url_unescape($password));
      last unless $chapscrt = `sudo scripts/mktgt $instance $username`;
      $template = $instance;
   }

   return $c->render(template => $template, username => $username, chapscrt => $chapscrt);
};

app->start;
END

This new version of the bootmenu application calls a custom mktgt script which, on success, returns a random CHAP password for each new iSCSI target that it creates. The CHAP password prevents one user from mounting another user's iSCSI target by indirect means. The app only returns the correct iSCSI target password to a user who has successfully authenticated.

The mktgt script is prefixed with sudo because it needs root privileges to create the target.

The $username and $chapscrt variables also pass to the render command so they can be incorporated into the templates returned to the user when necessary.

Next, update our boot templates so they can read the username and chapscrt variables and pass them along to the end user. Also update the templates to mount the root filesystem in rw (read-write) mode:

# cd $MY_MOJO/templates
# sed -i "s/:$MY_FC/:$MY_FC-<%= \$username %>/g" $MY_FC.html.ep
# sed -i "s/ netroot=iscsi:/ netroot=iscsi:<%= \$username %>:<%= \$chapscrt %>@/" $MY_FC.html.ep
# sed -i "s/ ro / rw /" $MY_FC.html.ep

After running the above commands, you should have boot templates like the following:

#!ipxe
kernel --name kernel.efi ${prefix}/vmlinuz-4.19.5-300.fc29.x86_64 initrd=initrd.img rw ip=dhcp rd.peerdns=0 nameserver=192.0.2.91 nameserver=192.0.2.92 root=/dev/disk/by-path/ip-192.0.2.158:3260-iscsi-iqn.edu.example.server-01:fc29-<%= $username %>-lun-1 netroot=iscsi:<%= $username %>:<%= $chapscrt %>@192.0.2.158::::iqn.edu.example.server-01:fc29-<%= $username %> console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet
initrd --name initrd.img ${prefix}/initramfs-4.19.5-300.fc29.x86_64.img
boot || chain https://server-01.example.edu/menu

NOTE: If you need to view the boot template after the variables have been interpolated, you can insert the "shell" command on its own line just before the "boot" command. Then, when you netboot your client, iPXE gives you an interactive shell where you can enter "imgstat" to view the parameters being passed to the kernel. If everything looks correct, you can type "exit" to leave the shell and continue the boot process.

Now allow the bootmenu user to run the mktgt script (and only that script) as root via sudo:

# echo "bootmenu ALL = NOPASSWD: $MY_MOJO/scripts/mktgt *" > /etc/sudoers.d/bootmenu

The bootmenu user should not have write access to the mktgt script or any other files under its home directory. All the files under /opt/bootmenu should be owned by root, and should not be writable by any user other than root.

Sudo does not work well with systemd's DynamicUser option, so create a normal user account and set the systemd service to run as that user:

# useradd -r -c 'iPXE Boot Menu Service' -d /opt/bootmenu -s /sbin/nologin bootmenu
# sed -i 's/^DynamicUser=true$/User=bootmenu/' /etc/systemd/system/bootmenu.service
# systemctl daemon-reload

Finally, create a directory for the copy-on-write overlays and create the mktgt script that manages the iSCSI targets and their overlayed backing stores:

# mkdir /$MY_FC.cow
# mkdir $MY_MOJO/scripts
# cat << 'END' > $MY_MOJO/scripts/mktgt
#!/usr/bin/env perl

# if another instance of this script is running, wait for it to finish
"$ENV{FLOCKER}" eq 'MKTGT' or exec "env FLOCKER=MKTGT flock /tmp $0 @ARGV";

# use "RETURN" to print to STDOUT; everything else goes to STDERR by default
open(RETURN, '>&', STDOUT);
open(STDOUT, '>&', STDERR);

my $instance = shift or die "instance not provided";
my $username = shift or die "username not provided";

my $img = "/$instance.img";
my $dir = "/$instance.cow";
my $top = "$dir/$username";

-f "$img" or die "'$img' is not a file"; 
-d "$dir" or die "'$dir' is not a directory";

my $base;
die unless $base = `losetup --show --read-only --nooverlap --find $img`;
chomp $base;

my $size;
die unless $size = `blockdev --getsz $base`;
chomp $size;

# create the per-user sparse file if it does not exist
if (! -e "$top") {
   die unless system("dd if=/dev/zero of=$top status=none bs=512 count=0 seek=$size") == 0;
}

# create the copy-on-write overlay if it does not exist
my $cow="$instance-$username";
my $dev="/dev/mapper/$cow";
if (! -e "$dev") {
   my $over;
   die unless $over = `losetup --show --nooverlap --find $top`;
   chomp $over;
   die unless system("echo 0 $size snapshot $base $over p 8 | dmsetup create $cow") == 0;
}

my $tgtadm = '/usr/sbin/tgtadm --lld iscsi';

# get textual representations of the iscsi targets
my $text = `$tgtadm --op show --mode target`;
my @targets = $text =~ /(?:^T.*\n)(?:^ .*\n)*/mg;

# convert the textual representations into a hash table
my $targets = {};
foreach (@targets) {
   my $tgt;
   my $sid;

   foreach (split /\n/) {
      /^Target (\d+)(?{ $tgt = $targets->{$^N} = [] })/;
      /I_T nexus: (\d+)(?{ $sid = $^N })/;
      /Connection: (\d+)(?{ push @{$tgt}, [ $sid, $^N ] })/;
   }
}

my $hostname;
die unless $hostname = `hostname`;
chomp $hostname;

my $target = 'iqn.' . join('.', reverse split('\.', $hostname)) . ":$cow";

# find the target id corresponding to the provided target name and
# close any existing connections to it
my $tid = 0;
foreach (@targets) {
   next unless /^Target (\d+)(?{ $tid = $^N }): $target$/m;
   foreach (@{$targets->{$tid}}) {
      die unless system("$tgtadm --op delete --mode conn --tid $tid --sid $_->[0] --cid $_->[1]") == 0;
   }
}

# create a new target if an existing one was not found
if ($tid == 0) {
   # find an available target id
   my @ids = (0, sort keys %{$targets});
   $tid = 1; while ($ids[$tid]==$tid) { $tid++ }

   # create the target
   die unless -e "$dev";
   die unless system("$tgtadm --op new --mode target --tid $tid --targetname $target") == 0;
   die unless system("$tgtadm --op new --mode logicalunit --tid $tid --lun 1 --backing-store $dev") == 0;
   die unless system("$tgtadm --op bind --mode target --tid $tid --initiator-address ALL") == 0;
}

# (re)set the provided target's chap password
my $password = join('', map(chr(int(rand(26))+65), 1..8));
my $accounts = `$tgtadm --op show --mode account`;
if ($accounts =~ / $username$/m) {
   die unless system("$tgtadm --op delete --mode account --user $username") == 0;
}
die unless system("$tgtadm --op new --mode account --user $username --password $password") == 0;
die unless system("$tgtadm --op bind --mode account --tid $tid --user $username") == 0;

# return the new password to the iscsi target on stdout
print RETURN $password;
END
# chmod +x $MY_MOJO/scripts/mktgt

The above script does five things:

1. It creates the /<instance>.cow/<username> sparse file if it does not already exist.
2. It creates the /dev/mapper/<instance>-<username> device node that serves as the copy-on-write backing store for the iSCSI target if it does not already exist.
3. It creates the iqn.<reverse-hostname>:<instance>-<username> iSCSI target if it does not exist. Or, if the target does exist, it closes any existing connections to it because the image can only be opened in read-write mode from one place at a time.
4. It (re)sets the chap password on the iqn.<reverse-hostname>:<instance>-<username> iSCSI target to a new random value.
5. It prints the new chap password on standard output if all of the previous tasks compeleted successfully.

You should be able to test the mktgt script from the command line by running it with valid test parameters. For example:

# echo `$MY_MOJO/scripts/mktgt fc29 jsmith`

When run from the command line, the mktgt script should print out either the eight-character random password for the iSCSI target if it succeeded or the line number on which something went wrong if it failed.

On occasion, you may want to delete an iSCSI target without having to stop the entire service. For example, a user might inadvertently corrupt their personal image, in which case you would need to systematically undo everything that the above mktgt script does so that the next time they log in they will get a copy of the original image.

Below is an rmtgt script that undoes, in reverse order, what the above mktgt script did:

# mkdir $HOME/bin
# cat << 'END' > $HOME/bin/rmtgt
#!/usr/bin/env perl

@ARGV >= 2 or die "usage: $0 <instance> <username> [+d|+f]\n";

my $instance = shift;
my $username = shift;

my $rmd = ($ARGV[0] eq '+d'); #remove device node if +d flag is set
my $rmf = ($ARGV[0] eq '+f'); #remove sparse file if +f flag is set
my $cow = "$instance-$username";

my $hostname;
die unless $hostname = `hostname`;
chomp $hostname;

my $tgtadm = '/usr/sbin/tgtadm';
my $target = 'iqn.' . join('.', reverse split('\.', $hostname)) . ":$cow";

my $text = `$tgtadm --op show --mode target`;
my @targets = $text =~ /(?:^T.*\n)(?:^ .*\n)*/mg;

my $targets = {};
foreach (@targets) {
   my $tgt;
   my $sid;

   foreach (split /\n/) {
      /^Target (\d+)(?{ $tgt = $targets->{$^N} = [] })/;
      /I_T nexus: (\d+)(?{ $sid = $^N })/;
      /Connection: (\d+)(?{ push @{$tgt}, [ $sid, $^N ] })/;
   }
}

my $tid = 0;
foreach (@targets) {
   next unless /^Target (\d+)(?{ $tid = $^N }): $target$/m;
   foreach (@{$targets->{$tid}}) {
      die unless system("$tgtadm --op delete --mode conn --tid $tid --sid $_->[0] --cid $_->[1]") == 0;
   }
   die unless system("$tgtadm --op delete --mode target --tid $tid") == 0;
   print "target $tid deleted\n";
   sleep 1;
}

my $dev = "/dev/mapper/$cow";
if ($rmd or ($rmf and -e $dev)) {
   die unless system("dmsetup remove $cow") == 0;
   print "device node $dev deleted\n";
}

if ($rmf) {
   my $sf = "/$instance.cow/$username";
   die "sparse file $sf not found" unless -e "$sf";
   die unless system("rm -f $sf") == 0;
   die unless not -e "$sf";
   print "sparse file $sf deleted\n";
}
END
# chmod +x $HOME/bin/rmtgt

For example, to use the above script to completely remove the fc29-jsmith target including its backing store device node and its sparse file, run the following:

# rmtgt fc29 jsmith +f

Once you've verified that the mktgt script is working properly, you can restart the bootmenu service. The next time someone netboots, they should receive a personal copy of the the netboot image they can write to:

# systemctl restart bootmenu.service

Users should now be able to modify the root filesystem as demonstrated in the below screenshot:

14 Jan 2019 8:00am GMT

Josh and Kurt talk about the EU bug bounty program. There have been a fair number of people complaining it's solving the wrong problem, but it's the only way the EU has to spend money on open source today. If that doesn't change this program will fail.



<iframe allowfullscreen="" height="90" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" scrolling="no" src="https://html5-player.libsyn.com/embed/episode/id/8242709/height/90/theme/custom/thumbnail/yes/preload/no/direction/backward/render-playlist/no/custom-color/6e6a6a/" style="border: none;" webkitallowfullscreen="" width="100%"></iframe>

Show Notes

• Josh's blog post
• Julia Reda EU bug bounty site
• Tidelift
• What motivates us

14 Jan 2019 12:58am GMT

Service 'The Koji Buildsystem' now has status: good: Everything seems to be working.

13 Jan 2019 10:04pm GMT

We had our first meeting of the year. The full logs from our meeting are available here on the Fedora mote application. I have pasted the minutes of the meeting at the end for your convenience.

The meeting was broadly for the team to come together and discuss a few things. We checked on the status of current tasks, and discussed our future steps. We've got to work on our documentation, for example. There's a lot to do, and a lot of cool new things to learn---in science, computing, and community development. If you'd like to get involved, please get in touch.

We're continuing our work on including software in NeuroFedora, since that's the major chunk of our work load.

---

13 Jan 2019 8:55pm GMT