Обновление Fedora c 32 до 36

Типичное обновление версии выглядит примерно вот так:

dnf upgrade --refresh
dnf install dnf-plugin-system-upgrade
dnf system-upgrade download --releasever=N
dnf system-upgrade reboot

где N - версия дистрибутива. Однако, все может пойти не по сценарию. Например, вот так.

Под катом инфа про то, как можно дойти до такого состояния и как из него выходить.

Отладка собранного в контейнере webassembly кода вне этого контейнера

Собирать webassebmly файл внутри docker-контейнера достаточно удобно, потому что не приходится следить за окружением и что-то постоянно доустанавливать и фиксить. Однако, есть небольшая тонкость при отладке собранных файлов.

Заключается она в том, что пути внутри контейнера и в любой другой среде скорее всего будут отличаться. Поэтому необходимо это учитывать при сборке. Например, есть файл test.c со следующим содержимым.

#include <stdlib.h>
#include <stdio.h>

int main() {
  int i = 0;
  for (int j = 0; j < 10; j++)
  {
	  i++;
  }
  return 0;
}

Собираем код следующей командой

docker run --expose=8080 --rm -v $(pwd):/src -u $(id -u):$(id -g) emscripten/emsdk emcc -g test.c -o test.html **-ffile-prefix-map=/src=$(pwd)**

Далее необходимо настроить свой браузер (на примере хрома) для отладки. После чего достаточно поднять любой веб-сервер для того, чтобы можно было обратиться к каталогу из браузера. Например, пакет serve из npm. Отладка webassembly кода станет доступна точно также, как и отладка js-кода.

Исправляем отсутствие доступа на запись в каталог внутри docker-контейнера

Иногда так бывает, что при монтировании каталога в контейнер необходимо иметь права на запись, однако по каким-то причинам запись недоступна

version: "3"
services:
  php:
    build:
      context: ./configs
      dockerfile: php74.dockerfile
    env_file:
      - configs/vars.env
    volumes:
      - .**/:/var/www**
      - ./configs/xdebug.ini:/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

Вот пример конфигурации, допустим внутри www есть каталог log, в который необходимо что-то писать. Для этого достаточно на хост-машине отредактировать права на каталог так, как это требуется для работы (ниже пример, не надо так делать без необходимости).

[dv4mp1r3@mbp ipinfo]$ ls -l | grep log
drwxrwxrwx. 2 dv4mp1r3 dv4mp1r3    4096 Jan  2 23:31 log

А происходить так может потому, что пользователь, из под которого запускается процесс внутри контейнера может не совпадать с владельцем каталога, поэтому и менять права надо вне контейнера.

Удаленная отладка с помощью xdebug 3

Совсем недавно (чуть больше месяца назад на момент написания) вышел xdebug версии 3.0.0. И сразу же после того, как докер подхватил изменения, удаленная отладка перестала работать.

А дело все в том, что в конфиге xdebug изменились названия параметров. Пример настройки для новой версии ниже.

xdebug.**mode=debug**
xdebug.**client_host**=172.17.0.1
xdebug.**client_port**=9001

Более подробно про переезд с 2.x на 3.x можно почитать в официальной документации.

UPD: необходимо экспортировать переменную для отладки cli-скриптов

export XDEBUG_SESSION=1