Convertion format XLSX into CSV on Fedora 39 (Problem 22 USE 2024)

 Original source has been taken from https://inf-ege.sdamgia.ru/problem?id=47604

Following below is updated and working version

(.env) boris@fedora:~/KEGE2024/D22$ cat djs22.py

import openpyxl
import csv  

from csv import reader

# input excel file path
inputExcel = '22_23.xlsx'
newWorkbook = openpyxl.load_workbook(inputExcel)
# getting the active workbook sheet(Bydefault-->Sheet1)
worksheet = newWorkbook.active
# Opening a output csv file in write mode
F = open("22_23.csv", 'w')
OutCsv = csv.writer(F,delimiter=";")
for eachrow in worksheet.rows:
    OutCsv.writerow([cell.value for cell in eachrow])
F.close()

"""

 Original code version proposed which requires manual Excel spreadsheet conversion to csv format 

"""

def f(d):
    if d[2] == [0]:
        return d[1]
    else:
        maxx = 0
        for i in d[2]:
            if maxx < f(index[i - 1]):
                maxx = f(index[i - 1])
        return maxx + d[1]
 
with open("22_23.csv") as F:
    s = reader(F, delimiter=';', quotechar='"')
    next(s)
    index = []
    for i in s:
        print(i)
        index.append([int(i[0]), int(i[1]), list(map(int, str(i[2]).split(';')))])
    for i in range(len(index)):
        print(i + 1, f(index[i])) 

(.env) boris@fedora:~/KEGE2024/D22$ python djs22.py
['1', '9', '0']
['2', '9', '1']
['3', '8', '2']
['4', '4', '1;2']
['5', '4', '1;4']
['6', '7', '4']
['7', '7', '0']
['8', '7', '3;5']
['9', '4', '6;7']
['10', '6', '8;9']
['11', '9', '2;3']
['12', '3', '8;9']
['13', '8', '6;7']
['14', '5', '8;10']
['15', '8', '4;11']
1 9
2 18
3 26
4 22
5 26
6 29
7 7
8 33
9 33
10 39
11 35
12 36
13 37
14 44
15 43

Используйте systemd-cryptenroll с FIDO U2F или TPM2 для расшифровки диска.

Источник https://fedoramagazine.org/use-systemd-cryptenroll-with-fido-u2f-or-tpm2-to-decrypt-your-disk/

Рабочая станция Fedora по умолчанию включает systemd-cryptenroll, что упрощает добавление альтернативных методов разблокировки разделов LUKS. В этой статье показано, как использовать микросхему TPM2 или ключ безопасности FIDO U2F в качестве альтернативы парольной фразе при разблокировке разделов LUKS.

Предыдущие статьи

Микросхема TPM2 — это небольшая часть хранилища с безопасными API, где вы можете хранить секреты, защищенные безопасной загрузкой. Безопасная загрузка устанавливает цепочку доверия путем вычисления хэшей на основе, например, аппаратных или программных компонентов. Таким образом, вы можете сохранить ключ дешифрования LUKS, который доступен только в том случае, если система находится в неподделанном состоянии (теоретически). К сожалению, это означает, что вы захотите измерять такие вещи, как ваши initramfs и ядро, в это состояние, что означает аннулирование этого фактора каждый раз, когда вы выполняете обновление системы. Ключи FIDO U2F не страдают от этой проблемы, поскольку они не привязаны к аппаратной платформе.

Прочтите мою предыдущую статью об использовании встроенного безопасного устройства хранения TPM2, чтобы узнать более подробные сведения о том, как работает разблокировка на основе TPM2 и как это влияет на безопасность.

https://fedoramagazine.org/automatically-decrypt-your-disk-using-tpm2/

Однако в предыдущей статье используется clevis, который добавляет дополнительные зависимости и имеет более сложный интерфейс, чем при использовании уже существующего systemd-cryptenroll.

Ключ, совместимый с FIDO2 или FIDO U2F, — это внешнее запоминающее устройство с безопасными API для хранения и извлечения секретов. Эти ключи можно использовать в качестве второго или единственного фактора в потоках аутентификации. Секреты никогда не покидают устройство, а проверка выполняется на клиенте. Таким образом, сценарии атак, такие как рыбалка, смягчены по дизайну по сравнению с другими технологиями MFA (многофакторная аутентификация), такими как TOTP (одноразовые пароли на основе времени).

В предыдущем сообщении о ключах FIDO U2F / FIDO2 здесь, в журнале Fedora, было показано, как настроить эти ключи для аутентификации Linux PAM — в первую очередь, для входа в систему sudo и GNOME. 

Найдите свои зашифрованные диски LUKS

Для следующих разделов вам потребуются пути файловой системы к зашифрованным разделам LUKS. Используйте lsblk, чтобы найти их.

$> lsblk

NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS

sda                     8:0    1     0B  0 disk

sdb                     8:16   1     0B  0 disk

zram0                 252:0    0     8G  0 disk  [SWAP]

nvme0n1               259:0    0 476.9G  0 disk

├─nvme0n1p1           259:1    0   600M  0 part  /boot/efi

├─nvme0n1p2           259:2    0     1G  0 part  /boot

└─nvme0n1p3           259:3    0 475.4G  0 part

  └─luks-fdb98c38-... 253:0    0 475.3G  0 crypt /home

                                                 /                                               

Найдите номер(а) раздела, на котором размещается раздел luks типа crypt. В данном случае это будет /dev/nvme0n1p3. Используйте этот путь в качестве цели для следующих разделов.

(Может быть) Избавьтесь от скобы

Предполагая, что вы следовали предыдущему сообщению об использовании TPM2, вы можете отвязать и удалить скобу, прежде чем продолжить работу с systemd-cryptenroll. В противном случае просто пропустите этот раздел.

Сначала удалите все привязки TPM2 из слотов секретов LUKS. Осторожно: не удаляйте слот 0, так как он содержит привязку парольной фразы!

Теперь удалите clevis packages.

sudo dnf remove -y clevis clevis-luks clevis-dracut clevis-udisks2 clevis-systemd

Выберите TPM2 или FIDO в качестве альтернативного метода расшифровки.

Следующие шаги необходимы для обоих методов. Выберите один по своему вкусу.

Добавьте соответствующий модуль dracut, чтобы поддержка была доступна в initramfs при загрузке.

Зарегистрируйте / привяжите секретный слот LUKS, привязанный либо к ключу TPM2, либо к ключу FIDO.

Обновите /etc/crypttab с новой конфигурацией.

Пересоберите initramfs, чтобы применить изменения

Важно запускать dracut последним, чтобы не только включить новые зависимости, но и обновленный crypttab в файл initramfs.

Используйте systemd-cryptenroll с ключом FIDO U2F.

Добавьте модуль fido2 dracut в конфигурацию dracut.

$ echo "add_dracutmodules+=\" fido2 \"" | sudo tee /etc/dracut.conf.d/fido2.conf

add_dracutmodules+=" fido2 "

Теперь зарегистрируйте ключ FIDO в разделе LUKS в качестве альтернативного фактора дешифрования. См. systemd-cryptenroll(1) для опций управления такими функциями, как сенсорное управление или подсказка пин-кода. По умолчанию присутствие и PIN-код запрашиваются для регистрации и использования.

$ sudo systemd-cryptenroll --fido2-device auto /dev/nvmen1p3

Обновите /etc/crypttab и добавьте fido2-device=auto к параметрам соответствующей строки. Строка в crypttab состоит из четырех полей, последнее из которых представляет собой список, разделенный запятыми.

Наконец, пересоберите ваши initramfs с помощью dracut. Следующая команда перестроит ваш текущий загруженный слот initramfs.

$ sudo dracut -f

Не беспокойтесь о том, что ключ FIDO не работает или может быть утерян, поскольку парольная фраза по-прежнему доступна в качестве запасного варианта.

Теперь при загрузке вам будет предложено ввести PIN-код вашего ключа FIDO. Имейте в виду, что запрос на ввод PIN-кода выглядит точно так же, как и запрос на ввод парольной фразы. Вы заметите разницу только при использовании терминала (его можно просмотреть, нажав клавишу ESC). После ввода правильного PIN-кода аппаратный токен предложит вам коснуться его, что (также) не указано в подсказке. Если он не запрашивает прикосновение, значит, systemd-cryptenroll не смог найти аппаратный токен, соответствующий введенному PIN-коду.

Примечание: в настоящее время systemd-cryptenroll не работает с несколькими подключенными аппаратными токенами.

Используйте systemd-cryptenroll с чипом TPM2.

Добавьте модуль tpm2-tss в конфигурацию dracut.

$ echo "add_dracutmodules+=\" tpm2-tss \"" | sudo tee /etc/dracut.conf.d/tpm2.conf

add_dracutmodules+=" tpm2-tss "

Зарегистрируйте чип TPM2 в качестве альтернативного фактора дешифрования для ваших разделов LUKS. Опция ‐wipe-slot tpm2 гарантирует, что после успешной регистрации все предыдущие привязки будут удалены. Используйте эту команду каждый раз, когда вам нужно обновить привязку.

$ sudo systemd-cryptenroll --wipe-slot tpm2 --tpm2-device auto --tpm2-pcrs "0+1+2+3+4+5+7+9" /dev/nvme0n1p3

Обновите /etc/crypttab и добавьте tpm2-device=auto,tpm2-pcrs=0+1+2+3+4+5+7+9 к параметрам соответствующей строки, в зависимости от используемых PCR. Строка в crypttab состоит из четырех полей, последнее из которых представляет собой список, разделенный плюсом.

И последнее, но не менее важное: пересоберите ваши initramfs с помощью dracut. Следующая команда перестроит ваш текущий загруженный слот initramfs.

$ sudo dracut -f

Why is there no registry in Linux unlike Windows OS?

 Источник :   https://www.quora.com/Why-is-there-no-registry-in-Linux-unlike-Windows-OS

Я бы начал с того, что перевернул вопрос: почему *в* Windows есть реестр, хотя многие операционные системы, как до, так и после, прекрасно обходятся без него?

Чтобы понять это, мы должны начать с истории. Реестр возник в Windows NT 3.1. В то время большинство потенциальных клиентов Windows NT уже работали с MS-DOS и имели диски в формате FAT. Большинство жестких дисков в то время использовали FAT 16, что ограничивало количество кластеров на диске. В терминах это означало, что большой диск (во всяком случае, большой по меркам того времени) часто имел довольно большие кластеры - 32 КБ и даже 64 КБ были довольно распространены. Это означало, что крошечные .ini-файлы, которые часто имели размер порядка десятков байт, по-прежнему занимали десятки килобайт дискового пространства каждый. Умножьте это на несколько тысяч (или около того), и вы получите *много* потраченного впустую дискового пространства (что в то время было довольно дорого).

Во-вторых, Windows 3.1 (и более ранние версии) довольно прямо использовали файлы .ini. То есть, когда вы читаете ключ из файла .ini, Windows открывает файл и линейно сканирует его, чтобы найти запрошенный раздел и ключ, а затем возвращает значение, которое вы связали с этим ключом. Когда файл .ini вообще был большим (а таких было много), это могло работать довольно медленно.

В-третьих, файлы .ini требовали большого количества преобразований. Даже самые тривиальные обычно включали такие вещи, как `foo = 1234`, которые требовали, чтобы `1234` читалось как текст и преобразовывалось в целое число для использования. Это тратит впустую как место для хранения, так и процессорное время.

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

Наконец, проблема курицы и яйца была решена. Изначально предполагалось, что Windows NT будет микроядром, то есть она будет иметь минимальную базовую ОС, обеспечиваемую микроядром. Затем микроядро будет предоставлять различные API-интерфейсы ОС в качестве «подсистем» пользовательского режима. Однако во время запуска микроядру требовался доступ к некоторым возможностям файловой системы, чтобы сообщать ему, например, какие подсистемы загружать и как их настраивать (потенциально включая такие вещи, как поддерживаемые каждой файловой системой). Итак, нам нужна файловая система, чтобы знать, как загружать и настраивать файловые системы.

По крайней мере, на первый взгляд, реестр решил все эти проблемы одним довольно простым махом. Он будет хранить множество мелких битов и фрагментов данных в нескольких больших файлах вместо огромного количества крошечных. Это была бы «правильная» база данных, поэтому она могла бы выполнять поиск быстрее, чем сканирование текстовых файлов. Он мог хранить любые дополнительные данные, необходимые для поддержки списков управления доступом, вместе с самими необработанными данными. Тип значения был назначен при сохранении этого значения, поэтому, если он хранил число, он преобразовывал текст в двоичный при его сохранении, и с этого момента он мог просто получить число в двоичном формате. И он будет (по крайней мере, вроде) встроен в ядро, поэтому он будет доступен даже до того, как будет загружена какая-либо подсистема ОС.

Теперь, безусловно, правда, что они могли бы сделать что-то по-другому. Например, они могли бы создать возможности, подобные реестру, в виде файловой системы, предназначенной для хранения большого количества небольших файлов, но при этом отвечающей обычным функциям файловой системы и тому подобному. Удаление конверсий было попыткой оптимизировать то, с чего изначально не было проблем. Если разобраться, то они все равно не встраивали реестр в микроядро - они просто обозначили подсистему Win32 как «первую среди равных», так что микроядро в любом случае зависело от подсистемы для этой функциональности.

В то же время я чувствую себя обязанным указать, что реестр действительно решил ряд довольно существенных проблем, и, вопреки тому, что многие из приведенных здесь ответов могли бы заставить поверить, Linux не просто сделал эту работу лучше во всех возможных аспектах. 

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

Во-вторых, в Windows реестр подтолкнул «проблему» в одном направлении. В Linux отсутствие реестра толкнуло его в другом направлении. В частности, под Windows хранение данных инициализации является проблемой, но сама инициализация в основном не является проблемой. В Linux хранение данных инициализации довольно простое, но сама инициализация гораздо менее проста - до такой степени, что некоторые разработчики Linux создали чудовище под названием «systemd» для запуска системы - но на самом деле это почти полная операционная система. Конечно, systemd - не единственный возможный способ инициализации системы Linux, но сделать это хорошо - головная боль для всех (? B.D.). Дело не только в том, что Microsoft изобрела проблему, которую весь остальной мир уже давно решил значительно более четко, или что-то в этом роде.

Также стоит упомянуть, что хотя конфигурация Linux на самом деле полностью зависит от обычных файлов, хранящихся в обычной файловой системе, вы все равно столкнетесь с некоторыми из тех же проблем, что и с реестром - вам придется использовать специальные утилиты для изменения файлов, а не чем просто редактировать их напрямую. В какой-то степени ситуация на самом деле еще хуже: если Windows, по крайней мере, изобрела единую систему для всех этих данных, то в Linux вы получаете уникальную утилиту с собственными уникальными переключателями командной строки (и тому подобным) практически для каждого файла, который вы загружаете, который не может/не должен просто открываться в текстовом редакторе (поэтому в типичной системе найдете как минимум полдюжины из них, а если вы внимательно посмотрели, вероятно, значительно больше).

Здесь на самом деле коренится страх перед UNIX/LINUX  B.D.

Общий доступ к папке между гостем Windows 11 и хостом Fedora 38 (KVM Hypervisor) с использованием virtiofs

 Источник :  https://www.debugpoint.com/kvm-share-folder-windows-guest/

Для управления Win11 KVM Guest использована Web Cockpit Console on Fedora 38 WKS

Установка Windows 11 в качестве KVM гостя на Ubuntu 22.04 с помощью virt-manager

 Источник  https://www.debugpoint.com/install-windows-ubuntu-virt-manager/

 

 

Just a picture

 

Hyperfunctions Theory per Akiro Kaneko