Сабж? Вот есть общий вывод утилиты journalctl, куда попадает всё (или почти всё, неважно). Нужно исключить вывод от некоторых конкретных демонов.
--unit, -u - показать сообщения от выбранного сервиса;
Комп на linux или венде. Есть что-нибудь работающее? Я вот не смог сейчас найти.
Нужно привести
bla1.YYYY-MM-DD.bla2.log
к виду
bla1.bla2.log.YYYY-MM-DD
где YYYY-MM-DD - это дата, которая может быть разная
Спасибо.
И вот опять, снова, это случилось. Ловлю ошибку на ноуте. Пишет, что причина - переполнения буфера AMD-VI. Может и так, не знаю. Знаю, что сетевая карта валится. Ок. Упало. Ребутаюсь - не загружается. Ок. Выключил - включил. Загрузилось. Хомяка нет. Провожу fsck для хомяка. Ок, хомяк монтируется. Директории Downloads Documents Pictures пусты. Девственно чисты. И такое уже не в первый раз. Ловил то же самое на этом ноуте, но с другим диском. Так что это НЕ диск. Вероятно, дохнет WI-FI адаптер. Однако, КАКОГО Х Я ТЕРЯЮ ПРИ ЭТОМ ДИСК. КАКОГО Х. Это трындец. Вот чтобы в венде вот так запросто потерять данные потому что у тебя сетевая отвалилась - лол што? Не-не-не, надо это говно гнать с железа. Не место этому недоделанному говну на железе.
Я закончил.
ЗЫ.
ФС - ext4
WI-FI - Intel Corporation Wireless 7260 (rev 73)
ЗЫ. Кажется, я забыл написать, что на проводе НЕ воспроизводится. Надо блин найти его родной вай-вай адаптер и исключить уже это.
Шлюз на linux. Как получить список прослушиваемых локально портов и список соединений к-от локальных процессов понятно. Как получить список проходящих мимо-дальше forwarded соединений?
Материнская плата Gigabyte TRX40 AORUS XTREME rev. 1.0
https://www.gigabyte.com/Motherboard/TRX40-AORUS-XTREME-rev-10
Помогите понять с методикой как вычислить устройство usb контроллера с целью выдать его целиком в гостя. И понять возможно ли вообще выдать его в гостя. Реализованные непосредственно в ЦП контроллеры пробрасываются? По идее, должны же?
Я так понимаю, что нужно взять известное конечное usb устройство, втыкать в порты и смотреть вывод lsusb (-t). Но как результат сопоставить с выводом lspci?
Запили наконец-то себе мультисит на базе sTRX4 с использованием proxmox. Собственно, у меня была рабочая ubuntu 16.04 и она целиком уехала в виртуальную машину. Диск целиком отдал, как был. Видяха та же, проброшена целиком. Мониторы те же. Всё работает, кроме DPMS. Экраны затемняются, но не гаснут. Поможете поправить? Что посмотреть?
Стримы
https://youtu.be/nf83yzzme2I - SpaceX
https://youtu.be/QlryDJqWalI - Tim Dodd
https://youtu.be/OLpN8Cco3mU - NSF
Смешной вопрос, да. Кто? Кто это делает? Кто резолвит имена в том же debian 10 из коробки?
Мне поиск не смог помочь ((
Массив
root@host103:~# mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Fri Nov 6 20:36:47 2020
Raid Level : raid6
Array Size : 92273631232 (87998.99 GiB 94488.20 GB)
Used Dev Size : 11534203904 (10999.87 GiB 11811.02 GB)
Raid Devices : 10
Total Devices : 10
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Mon Nov 9 04:17:49 2020
State : active, checking
Active Devices : 10
Working Devices : 10
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Consistency Policy : bitmap
Check Status : 0% complete
Name : host103:2 (local to host host103)
UUID : 4e5483ae:2e82d657:2ec42c81:1593e833
Events : 13709
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
2 8 65 2 active sync /dev/sde1
3 8 81 3 active sync /dev/sdf1
4 8 97 4 active sync /dev/sdg1
5 8 113 5 active sync /dev/sdh1
6 8 129 6 active sync /dev/sdi1
7 8 145 7 active sync /dev/sdj1
8 8 161 8 active sync /dev/sdk1
9 8 177 9 active sync /dev/sdl1
root@host103:~#
из дисков
root@host103:~# fdisk -l /dev/sdc
Disk /dev/sdc: 10.94 TiB, 12000138625024 bytes, 23437770752 sectors
Disk model: TOSHIBA MG07ACA1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: CC7399F1-714A-4ECF-B7A8-79BB1767F1B7
Device Start End Sectors Size Type
/dev/sdc1 2048 23068674047 23068672000 10.8T Linux filesystem
root@host103:~#
root@host103:~# smartctl -i -A /dev/sdc
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-52-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Toshiba MG07ACA... Enterprise Capacity HDD
Device Model: TOSHIBA MG07ACA12TE
Serial Number: 20B0A2AQFDUG
LU WWN Device Id: 5 000039 9f8cb26c8
Firmware Version: 4003
User Capacity: 12,000,138,625,024 bytes [12.0 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Mon Nov 9 04:18:41 2020 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0
2 Throughput_Performance 0x0005 100 100 050 Pre-fail Offline - 0
3 Spin_Up_Time 0x0027 100 100 001 Pre-fail Always - 7148
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 10
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 100 100 050 Pre-fail Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 85
10 Spin_Retry_Count 0x0033 100 100 030 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 10
23 Helium_Condition_Lower 0x0023 100 100 075 Pre-fail Always - 0
24 Helium_Condition_Upper 0x0023 100 100 075 Pre-fail Always - 0
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 9
193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 15
194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 27 (Min/Max 19/27)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
220 Disk_Shift 0x0002 100 100 000 Old_age Always - 2228224
222 Loaded_Hours 0x0032 100 100 000 Old_age Always - 61
223 Load_Retry_Count 0x0032 100 100 000 Old_age Always - 0
224 Load_Friction 0x0022 100 100 000 Old_age Always - 0
226 Load-in_Time 0x0026 100 100 000 Old_age Always - 594
240 Head_Flying_Hours 0x0001 100 100 001 Pre-fail Offline - 0
root@host103:~#
Диски подключены к контроллеру PERC H730 Mini (Embedded) в режиме HBA (шасси PowerEdge R730xd)
Поверх лежит LVM.
root@host103:~# vgs
VG #PV #LV #SN Attr VSize VFree
vg01 1 4 0 wz--n- 439.87g 399.87g
vg02 1 3 0 wz--n- <85.94t <158.99g
root@host103:~#
root@host103:~# lvs | grep -e LV -e test
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
test-begin vg02 -wi-ao---- 400.00g
test-end vg02 -wi-a----- 400.00g
test-middle vg02 -wi-a----- 85.00t
root@host103:~#
Показывает на операции
root@host103:~# shred -n0 -z -vv /dev/mapper/vg02-test--begin
shred: /dev/mapper/vg02-test--begin: pass 1/1 (000000)...
shred: /dev/mapper/vg02-test--begin: pass 1/1 (000000)...145MiB/400GiB 0%
скорость на запись около 30 мебибайт в секунду. Это нормально?
Прямо сейчас идёт ресинк, я руками запустил. На момент прогона shred ресинка не было.
root@host55:~# blkid /dev/md0 /dev/md0: UUID=«284545ce-198a-4b72-ba1c-6e70ce5b07b2» TYPE=«ext4» root@host55:~# blkid /dev/sda1 /dev/sda1: UUID=«5a65a95e-5e82-45fb-db79-922ad172f63f» UUID_SUB=«a0955b48-64f6-1262-e32e-578d20d2fe76» LABEL=«sysresccd:0» TYPE=«linux_raid_member» PARTUUID=«90481f0b-01» root@host55:~# blkid /dev/sdb1 /dev/sdb1: UUID=«5a65a95e-5e82-45fb-db79-922ad172f63f» UUID_SUB=«00ce8aaa-8c2a-bc1e-9e93-eb32196439d6» LABEL=«sysresccd:0» TYPE=«linux_raid_member» PARTUUID=«f2f3bc51-01» root@host55:~# blkid /dev/sdc1 /dev/sdc1: UUID=«5a65a95e-5e82-45fb-db79-922ad172f63f» UUID_SUB=«fc92f06b-1772-1336-8027-0144fd35b6e9» LABEL=«sysresccd:0» TYPE=«linux_raid_member» PARTUUID=«18f86591-01» root@host55:~# blkid /dev/sdd1 /dev/sdd1: UUID=«5a65a95e-5e82-45fb-db79-922ad172f63f» UUID_SUB=«b51d13ba-9947-2510-39b9-7596696256d5» LABEL=«sysresccd:0» TYPE=«linux_raid_member» PARTUUID=«694ca63f-01» root@host55:~# root@host55:~# grep boot /etc/fstab # /boot was on /dev/md0 during installation UUID=284545ce-198a-4b72-ba1c-6e70ce5b07b2 /boot/ ext4 defaults 0 2 root@host55:~#
Кто-нибудь может объяснить как это работает?
Это же зеркало. Почему мы имеем несколько разных uuid у одной ФС? Или я неправильно понимаю суть uuid? uuid - это про что? Это про устройство или про файловую систему? Мы в систему монтируем ФС или устройство?
Провели успешное static fire тестирование. Прямо сейчас было.
https://youtu.be/1rj-tMlbrM0
https://youtu.be/720cYnsfM0I
https://t.me/SpaceX/4655
https://twitter.com/elonmusk/status/1288928622728712192
Далее ждём подъём на 150 метров, горизонтальное маневрирование и спуск.
В общем, я наступил на какие-то грабли. Или не наступил. Непонятно.
Сделал на raw образе ВМ (образ файлом)
virsh blockresizeи получил что-то непонятное. Команда virsh blockresize отработало нормально, но изменился только virtual size. Размер файла образа при этом НЕ изменился.
Потом я сделал
qemu-img resizeи размер файла стал соответствовать, НО disk size НЕ изменился.
Сейчас наблюдаю такую картину
root@host31:/storage/images# qemu-img info name.img image: name.img file format: raw virtual size: 200G (214748364800 bytes) disk size: 101G root@host31:/storage/images#
и я понятия не имею что с этим делать. Оставить как есть? Как-то исправить? Создать новый образ на замену и перелить данные? В общем, нужна помощь.
Держу в курсе.
Сетап:
Рабочая машина на ubuntu 16.04 на AM3+. Поставил на эту машину модули с ECC на НГ 2019-2020. На этой машине три диска по 8000G под хранение всякого восстановимого барахла.
Игровая машина на windows 10 на 1155 с «обычными» модулями.
Клиентом uTorrent проводил перехеширование (данных достаточно много для оценки, на слово поверьте). Итого:
Вариант исходный. Диски на машине с ECC расшарены в сеть самбой и подключены к игровой, на которой работает uTorrent. Перехеширование проводил периодически, специально. Ошибки стабильно были, на около 10% торрентов.
Вариант текущий. На рабочей машине поднял виртуальную машину с windows 10 и выдал ей диски целиком. Клиент uTorrent работает в этой виртуалке. Диска выданы в сеть силами этой же виртуальной венды. Ошибок НЕТ. Я прогнал два раза - НИ ОДНОЙ ОШИБКИ. Прогон перехеширования занимает более 2 суток.
Делайте выводы.
Участвует ли MX-запись в DNS где-нибудь при рассылке? Может быть, проверки есть какие-нибудь на принимающей стороне? Поделитесь историями.
Кто бы мог подумать и предполагать.
https://ria.ru/20200505/1570987371.html
Задался тут вопросом. Вот, например, есть у меня otrs или redmine какой-нибудь и есть несколько разных доменов со своими SSL парами. Могу ли я запилить все эти адреса и ssl пары в один конфиг в nginx? Сущность-то одна. Или надо для каждого домена свой конфиг держать?
Спасибо.
Мне надо при старте машины запускать сессию tmux, поделённую на 4 «окошка», горизонтально, с пингами там. Помогите. Спасибо.
Вот у контроллера PERC H730P я вижу Patrol Read Mode, которое, возможно (я не знаю достоверно), как раз этим занимается - фоновым перепрочтением диска на предмет его жизнеспособности. А что насчет linux raid? Оно так умеет?
Есть уже существующий рабочий сетап ipsec на базе ipsec-tools + racoon (старые машины), к которым надо подключить свежую машину с ipsec на strongswan.
У существующего сетапа:
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
Что-то я не соображу что на стороне strongswan надо указать. 0
ike=3des-sha1-modp1024! esp=3des-sha1Так?
В общем, сейчас я на стороне racoon получаю сообщения вида
ERROR: invalid flag 0x08.
На стороне strongswan получаю сообщения вида
parsed ID_PROT request 0 [ ID HASH ] looking for pre-shared key peer configs matching found 1 matching config, but none allows pre-shared key authentication using Main Mode generating INFORMATIONAL_V1 request 3754429371 [ HASH N(AUTH_FAILED) ]
Из поиска внятного ответа я не смог получить (((
Что я делаю не так? Помогите, пожалуйста.
| ← назад | следующие → |