NixTux https://nixtux.ru На этом сайте делимся опытом, скриптами и советами в Linux и Свободных программах Thu, 02 Jul 2020 10:36:31 +0000 ru-RU hourly 1 https://wordpress.org/?v=5.4.2 Алгоритм починки BTRFS https://nixtux.ru/1024 https://nixtux.ru/1024#respond Thu, 02 Jul 2020 10:36:31 +0000 https://nixtux.ru/?p=1024 Читать далее Алгоритм починки 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
version.
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»).

==Interlude==
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:
https://www.suse.com/documentation/sles-12/stor_admin/data/sect_filesystems_trouble.html

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
choice.
==

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»

Источник

]]>
https://nixtux.ru/1024/feed 0
Хренак, хренак и зарелизили Федору https://nixtux.ru/1021 https://nixtux.ru/1021#respond Tue, 30 Jun 2020 22:36:19 +0000 https://nixtux.ru/?p=1021 Читать далее Хренак, хренак и зарелизили Федору]]> Выкачал копии репозиториев Fedora, выкачивал так:

mkdir -p fedora/linux/releases/31/Everything/x86_64/os/Packages/
rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync://mirror.yandex.ru/fedora/linux/releases/31/Everything/x86_64/os/Packages/ 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://mirror.yandex.ru/fedora/linux/releases/30/Everything/x86_64/os/Packages/ 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://mirror.yandex.ru/fedora/linux/releases/32/Everything/x86_64/os/Packages/ 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
    1121
[root@nas-dfly ~]# find fedora/linux/releases/32/Everything/x86_64/os/Packages -type f -name '*.rpm' | wc -l
   55327

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

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

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

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

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

]]>
https://nixtux.ru/1021/feed 0
Обновление переводов в исходниках drakxtools https://nixtux.ru/1016 https://nixtux.ru/1016#respond Sun, 26 Apr 2020 22:09:36 +0000 https://nixtux.ru/?p=1016 Все время забываю, как это делается, каждый раз приходится догадываться по Makefile, поэтому запишу процедуру обновления переводов после правки кода drakxtools.

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

]]>
https://nixtux.ru/1016/feed 0
Видео по работе с Git на примере пакетов в ROSA https://nixtux.ru/1009 https://nixtux.ru/1009#respond Thu, 09 Apr 2020 18:57:34 +0000 https://nixtux.ru/?p=1009

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

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

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

]]>
https://nixtux.ru/1009/feed 0
Изощренное создание %pre скриптлета RPM-пакета из шаблона https://nixtux.ru/1002 https://nixtux.ru/1002#respond Tue, 24 Mar 2020 23:25:54 +0000 https://nixtux.ru/?p=1002 Читать далее Изощренное создание %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 вот так:

%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@ 
SYSTEMD_INLINE_EOF

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

%pre
%{expand:
%(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
<...>
%pre

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 
SYSTEMD_INLINE_EOF 

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

]]>
https://nixtux.ru/1002/feed 0
КриптоПро, ошибка при создании контейнера: ctkey.c:1894:GenKey() Error number 0x80090020 https://nixtux.ru/999 https://nixtux.ru/999#comments Mon, 17 Feb 2020 05:58:56 +0000 https://nixtux.ru/?p=999 При выполнении команды 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/librdrrndmbio_gui_fgtk.so /opt/cprocsp/lib/amd64/librdrrndmbio_gui_fgtk.so.bak
По всей видимости, оно пыталось открыть окошко для генерации энтропии мышкой, но не могло это сделать в chroot без доступа к X-серверу.

]]>
https://nixtux.ru/999/feed 1
Проверка DKIM и SPF из консоли на Linux https://nixtux.ru/995 https://nixtux.ru/995#comments Tue, 28 Jan 2020 11:56:13 +0000 https://nixtux.ru/?p=995 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.

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

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

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

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

]]>
https://nixtux.ru/990/feed 0
Порядок применения макросов в RPM 4 https://nixtux.ru/988 https://nixtux.ru/988#respond Fri, 03 Jan 2020 20:20:45 +0000 https://nixtux.ru/?p=988 /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@)

]]>
https://nixtux.ru/988/feed 0
API ABF для получения списка прикрепленных к платформе репозиториев https://nixtux.ru/983 https://nixtux.ru/983#respond Fri, 03 Jan 2020 18:29:12 +0000 https://nixtux.ru/?p=983 https://abf.rosalinux.ru/api/v1/platforms/5777/projects (авторизация не требуется)
где 5777 — ID платформы.

Список платформ в JSON: https://abf.rosalinux.ru/api/v1/platforms?type=main&per_page=100 (требуется авторизация)

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

]]>
https://nixtux.ru/983/feed 0