NixTux На этом сайте делимся опытом, скриптами и советами в Linux и Свободных программах Thu, 02 Jul 2020 10:36:31 +0000 ru-RU hourly 1 Алгоритм починки BTRFS Thu, 02 Jul 2020 10:36:31 +0000 Читать далее Алгоритм починки BTRFS]]> Скопирую сюда хорошее описание порядка действия для починки BTRFS. На английском.

The below are the steps I would recommend for ANY btrfs issue, smart
people reading dmesg or syslog can probably figure out which of these
steps they’d need to skip to in order to fix their particular problem.

Step 1 — boot to a suitable alternative system, such as a different
installation of openSUSE, a liveCD, or an openSUSE installation DVD.
The installation DVD for the version of openSUSE you are running is
usually the best choice as it will certainly use the same kernel/btrfs
Step 2 — Go to a suitable console and make sure you do the below as root
Step 3 — Try to mount your partition to /mnt, just to confirm it’s
really broken (eg. «mount /dev/sda1 /mnt»)
Step 4 — If it mounts — are you sure it’s broken? if Yes — run «btrfs
scrub start /mnt» to scrub the system, and «btrfs scrub status /mnt»
to monitor it
Step 5 — If it doesn’t mount, try to scrub the device just in case it
works (eg. «btrfs scrub start /dev/sda1» and «btrfs scrub status
/dev/sda1» to monitor). Try mounting, if yes, you’re fixed.
Step 6 — If scrubbing is not an option or does not resolve the issue
then try «mount -o usebackuproot» instead (eg. «mount -o usebackuproot
/dev/sda1 /mnt»).

All of the above steps are considered safe and should make no
destructive changes to disk, and have fixed every filesystem issue
I’ve had on btrfs in the last 5 years
Full disk issues need a different approach (basically, delete stuff
;)) documented here:

If the above doesn’t fix things for you, you can continue with the
below steps but the situation is serious enough to justify a bug
report, please!

Step 7 — Run «btrfs check » (eg. «btrfs check /dev/sda1»).
This isn’t going to help, but save the log somewhere, it will be
useful for the bug report.
Step 8 — Seriously consider running «btrfs restore » (eg. «btrfs restore /dev/sda1 /mnt/usbdrive»). This
won’t fix anything but it will scan the filesystem and recover
everything it can to the mounted device. This especially useful if
your btrfs issues are actually caused by failing hardware and not
btrfs fault.
Step 9 — Run «btrfs rescue super-recover » (eg. «btrfs rescue
super-recover /dev/sda1»). Then try to mount the device normally. If
it works, stop going.
Step 10 — Run «btrfs rescue zero-log » (eg. «btrfs rescue
zero-log /dev/sda1»). Then try to mount the device normally. If it
works, stop going.
Step 11 — Run «btrfs rescue chunk-recover » (eg. «btrfs rescue
chunk-recover /dev/sda1»). This will take a LONG while. Then try to
mount the device normally. If it works, stop going.
Step 12 — Don’t just consider it this time, don’t be an idiot, run
«btrfs restore » (eg. «btrfs restore
/dev/sda1 /mnt/usbdrive»).
Step 13 — Seriously, don’t be an idiot, use btrfs restore

==Danger zone=
The above tools had a small chance of making unwelcome changes, but
now you’re in the seriously suicidal territory, do not do the
following unless you’re prepared to accept the consequences of your

Step 14 — Now, ONLY NOW, try btrfsck aka «btrfs check —repair
» (eg. «btrfs check —repair /dev/sda1»)

There, I’m very confident the above will help you Andrei, and for
everyone else, can we please bury the nonsense that btrfs is lacking
when it comes to repair and recovery tools?

You have scrub which is safe for day to day use, the perfectly safe
usebackuproot mount option, and the various «btrfs rescue» commands
which are only moderately worrying compared to the practical Russian
roulette which is «btrfs check»


]]> 0
Хренак, хренак и зарелизили Федору Tue, 30 Jun 2020 22:36:19 +0000 Читать далее Хренак, хренак и зарелизили Федору]]> Выкачал копии репозиториев Fedora, выкачивал так:

mkdir -p fedora/linux/releases/31/Everything/x86_64/os/Packages/
rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync:// fedora/linux/releases/31/Everything/x86_64/os/Packages/
mkdir -p fedora/linux/releases/30/Everything/x86_64/os/Packages/
rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync:// fedora/linux/releases/30/Everything/x86_64/os/Packages/
mkdir -p fedora/linux/releases/32/Everything/x86_64/os/Packages/
rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync:// fedora/linux/releases/32/Everything/x86_64/os/Packages/

Немного проанализируем их. Посмотрим, сколько пакетов в репозитории fc32 имеют суффикс не fc32, т.е. не были пересобраны с предыдущего релиза:

[root@nas-dfly ~]# find fedora/linux/releases/32/Everything/x86_64/os/Packages -type f -name '*.rpm' | grep -v '\.fc32\.' | wc -l
[root@nas-dfly ~]# find fedora/linux/releases/32/Everything/x86_64/os/Packages -type f -name '*.rpm' | wc -l

1121 / 55327 = 2% пакетов в момент релиза Fedora 32 не пересобирались и были просто скопированы из предыдущих релизов. Возможно, некоторые починили и положили в updates, я смотрю только release, но это не столь важно, ведь некоторые пакеты не пересобираются несколько релизов подряд:

[root@nas-dfly ~]# find fedora/linux/releases/31/Everything/x86_64/os/Packages -type f -name '*.fc2*.*' | wc -l

Т.е. 110 пакетов не пересобирались более двух релизов, более года (релиз выходит раз в полгода).

Некоторые пакеты имеют сломанные зависимости, например:

 Problem: conflicting requests
  - nothing provides mvn(org.hibernate:hibernate-validator) needed by jersey-2.28-5.fc31.noarch
  - nothing provides mvn( needed by jersey-2.28-5.fc31.noarch
(try to add '--skip-broken' to skip uninstallable packages)

Был лучшего мнения о качестве репозиториев Fedora. С другой стороны, для такой быстрой модели разработки не так уж и плохо.

]]> 0
Обновление переводов в исходниках drakxtools Sun, 26 Apr 2020 22:09:36 +0000 Все время забываю, как это делается, каждый раз приходится догадываться по Makefile, поэтому запишу процедуру обновления переводов после правки кода drakxtools.

cd perl-install/share/po
make libDrakX.pot (это добавит новую строку, в данном случае America/Nuuk, в шаблон с переводами)
make merge (обновить po из шаблона pot)
Дописать перевод в ru.po
make merge еще раз для форматирования po

]]> 0
Видео по работе с Git на примере пакетов в ROSA Thu, 09 Apr 2020 18:57:34 +0000

Git-ветки на примере пакета в ROSA. Часть 1. git merge веток

Git. Часть 2. Откат изменений. Форс-пуш

Git-ветки на примере пакета в ROSA. Часть 3. Быстрый merge из master во все остальные ветки

]]> 0
Изощренное создание %pre скриптлета RPM-пакета из шаблона Tue, 24 Mar 2020 23:25:54 +0000 Читать далее Изощренное создание %pre скриптлета RPM-пакета из шаблона]]> Дано:
файл quagga-sysusers.conf («Source3: quagga-sysusers.conf» в RPM-спеке) с таким содержимым:

u @quagga_user@ - "Quagga routing suite user" /run/quagga
g @quagga_user@ -
m @quagga_user@ @quagga_user@
g @vty_group@ -
m @quagga_user@ @vty_group@

При этом хочется использовать этот конфиг systemd-sysusers в предустановочном скриптлете RPM-пакета (%pre). Но нужно шаблоны @quagga_user@ и @vty_group@ заменить на их значения.

Стандартно конфиг systemd-sysusers добавляется в %pre вот так:

%sysusers_create_package %{name} %{SOURCE3}

что превращается в:

$ rpm -qp --scripts quagga-1.2.4-3-rosa2016.1.x86_64.rpm
preinstall scriptlet (using /bin/sh):

systemd-sysusers --replace=/usr/lib/sysusers.d/quagga.conf - </dev/null 2>&1 || : 
u @quagga_user@ - "Quagga routing suite user" /run/quagga
g @quagga_user@ -
g @vty_group@ -
m @quagga_user@ @vty_group@ 

Вот как бы это прогнать через sed? Решение такое:

%(echo '%{sysusers_create_package %{name} %{SOURCE3}}' | \
sed -e 's,@quagga_user@,%{quagga_user},g' -e 's,@vty_group@,%{vty_group},g')

Убеждаемся, что это превратится в то, что нужно:

$ cp -v quagga-sysusers.conf ~/rpmbuild/SOURCES/
$ rpmspec --parse quagga.spec

systemd-sysusers --replace=/usr/lib/sysusers.d/quagga.conf - </dev/null 2>&1 || : 
u quagga - "Quagga routing suite user" /run/quagga
g quagga -
m quagga quagga
g quaggavt -
m quagga quaggavt 

Обратите внимание на одинарные кавычки в строке '%{sysusers_create_package %{name} %{SOURCE3}}', иначе двойные кавычки в "Quagga routing suite user" теряются.

]]> 0
КриптоПро, ошибка при создании контейнера: ctkey.c:1894:GenKey() Error number 0x80090020 Mon, 17 Feb 2020 05:58:56 +0000 При выполнении команды csptest -keyset -provtype 75 -newkeyset -cont '\\.\HDIMAGE\container_name' в CryptoPro внутри контейнера systemd-nspawn возникала ошибка:
ctkey.c:1894:GenKey() Error number 0x80090020
Пришлось запустить под strace, чтобы придумать решение:
mv -v /opt/cprocsp/lib/amd64/ /opt/cprocsp/lib/amd64/
По всей видимости, оно пыталось открыть окошко для генерации энтропии мышкой, но не могло это сделать в chroot без доступа к X-серверу.

]]> 1
Проверка DKIM и SPF из консоли на Linux Tue, 28 Jan 2020 11:56:13 +0000 dig +short TXT domain.tld
dig +short TXT @ns1.domain.tld. domain.tld
spfquery --scope mfrom --id info@domain.tld --ip 111.222.333.444 --helo-id webserver1.domain.tld
Взято из Acymailing.

]]> 1
Переадресация с без www на www на nginx под управлением панели Vesta CP Mon, 27 Jan 2020 20:45:14 +0000 (301-ый редирект). При этом с http есть переадресация на https. Правки конфигов nginx следующие: root@webserver1:/home/admin/conf/web# diff -u --- 2020-01-27 23:30:22.338398636 +0300 +++ 2020-01-27 23:32:11.117733083 +0300 @@ -2,7 +2,7 @@ listen … Читать далее Переадресация с без www на www на nginx под управлением панели Vesta CP]]> Понадобилось на Vesta CP сделать следующее: конфигом nginx обеспечить переадресацию сайта с без www на сайт c www: -> (301-ый редирект). При этом с http есть переадресация на https.

Правки конфигов nginx следующие:

root@webserver1:/home/admin/conf/web# diff -u
---	2020-01-27 23:30:22.338398636 +0300
+++	2020-01-27 23:32:11.117733083 +0300
@@ -2,7 +2,7 @@
     location / {
-        rewrite ^(.*)$1 permanent;
+        rewrite ^(.*)$1 permanent;
 include /home/admin/conf/web/*;
root@webserver1:/home/admin/conf/web# diff -u
---	2020-01-27 23:28:22.155122997 +0300
+++	2020-01-27 23:38:32.071351178 +0300
@@ -1,6 +1,16 @@
 server {
+    listen;
+    server_name;
+    return       301$request_uri;
+    ssl         on;
+    ssl_certificate      /home/admin/conf/web/;
+    ssl_certificate_key  /home/admin/conf/web/;
+    error_log  /var/log/apache2/domains/ error;
+server {
-    server_name;
+    server_name;
     ssl         on;
     ssl_certificate      /home/admin/conf/web/;
     ssl_certificate_key  /home/admin/conf/web/;

Обратите внимание, что нужно сделать отдельный раздел «server» для сайта без www и отдельный для сайта с www, чтобы из первого направить во второй, и при этом нужно не забыть к новому разделу подцепить SSL-сертификат от старого.

]]> 0
Порядок применения макросов в RPM 4 Fri, 03 Jan 2020 20:20:45 +0000 /usr/lib/rpm/openmandriva/macros -> /usr/lib/rpm/macros.d -> /etc/rpm/macros -> /etc/rpm/macros.d -> ~/.rpmmacros -> spec (от ngompa@)]]> /usr/lib/rpm/macros -> /usr/lib/rpm/openmandriva/macros -> /usr/lib/rpm/macros.d -> /etc/rpm/macros -> /etc/rpm/macros.d -> ~/.rpmmacros -> spec
(от ngompa@)

]]> 0
API ABF для получения списка прикрепленных к платформе репозиториев Fri, 03 Jan 2020 18:29:12 +0000 (авторизация не требуется)
где 5777 — ID платформы.

Список платформ в JSON: (требуется авторизация)

ID платформ:
rosa2014.1 — 878
rosa2016.1 — 1550
rosa2019.0 — 5777
rosa2019.05 — 12563
rosa2019.1 — 4084

]]> 0