From: Dmitry Kolvakh 2:5054/89.2 11 Jul 2020 21:24 +0300
To: Eugene Grosbein grosbein.net
Subject: OpenVPN - очень низкая скорость загрузки, нормальная скорость выгр
Hello Eugene! 11 Jul 20 06:59, you wrote to me: EG> Subject: Re: OpenVPN - очень низкая скорость загрузки, нормальная EG> скорость выгрузки EG> 10 июля 2020, пятница, в 17:48 NOVT, Dmitry Kolvakh написал(а): DK>> Поставил openvpn-2.4.8_2 на 12.1-RELEASE в качестве сервера. DK>> Протокол udp, интерфейс tun. Шлюз по умолчанию не отдается, DK>> только пушится маршрутизация нужных сетей. NAT не используется, DK>> только в rc.conf gateway_enable="YES" Получился пренеприятный DK>> эффект. Скорость загрузки с маршрутизируемых сетей просто никакая DK>> - 5KB/s с виртуальных машин на FreeBSD, порядка 700KB/s с DK>> железной машине на Linux. Уже эта разница настораживает. При DK>> этом скорость _выгрузки_ в маршрутизируемые сети - нормальная, DK>> 9MB/s. EG> Опиши железо: точную модель сетевой карты и CPU. Сервер на виртуалке под proxmox. CPU: Common KVM processor (2600.01-MHz K8-class CPU) Origin="GenuineIntel" Id=0xf61 Family=0xf Model=0x6 Stepping=1 Features=0x1783fbff Features2=0x80202001 AMD Features=0x20100800 AMD Features2=0x1 real memory = 2147483648 (2048 MB) avail memory = 2043162624 (1948 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) На физическом хосте 32 x Intel Xeon E5-2680 0 @ 2.70GHz (2 sockets) Сетевая: vtnet0: on virtio_pci3 vtnet0: Ethernet address: 26:da:78:ff:a9:fd vtnet0: netmap queues/slots: TX 1/256, RX 1/128 Точную модель железа не знаю, если это важно - спрошу. EG> Покажи вывод ifconfig для физической сетевой и для tun0. vtnet0: flags=8843 metric 0 mtu 1500 options=6c07bb ether 26:da:78:ff:a9:fd inet xx.xx.xx.xx netmask 0xfffffff0 broadcast xx.xx.xx.xx media: Ethernet 10Gbase-T status: active nd6 options=29 tun0: flags=8051 metric 0 mtu 1500 options=80000 inet6 fe80::5c2d:faf0:33a7:6ab0%tun0 prefixlen 64 scopeid 0x3 inet 10.100.22.1 --> 10.100.22.2 netmask 0xffffff00 groups: tun nd6 options=21 Opened by PID 2383 DK>> sndbuf 524288 DK>> rcvbuf 524288 DK>> push "sndbuf 524288" DK>> push "rcvbuf 524288" EG> Покажи выдачу sysctl net.inet | fgrep buf net.inet.tcp.sendbuf_auto_lowat: 0 net.inet.tcp.sendbuf_max: 2097152 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.recvbuf_max: 2097152 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.sctp.buffer_splitting: 0 net.inet.sctp.max_chained_mbufs: 5 Dmitry
From: Eugene Grosbein grosbein.net 30 Jun 2020 18:15 +0300
To: Alex Korchmar ddt.demos.su
Subject: Master Boot Record
29 июня 2020, понедельник, в 20:39 NOVT, Alex Korchmar написал(а): EG>> Если бы я любил попкорн, мне понадобилась бы тонна. AK> ты еще помнишь, как денежки волонтеров потратили на лекцию о гендерном AK> равенстве? Hет. Я не слежу за активностью фаундейшна. Eugene
From: Ruslan Suleimanov 2:467/888 28 Jun 2020 23:07 +0300
To: Eugene Grosbein grosbein.net
Subject: PV в OCI
Привет, Eugene! Ответ на сообщение Eugene Grosbein (2:5006/1) к Ruslan Suleimanov, написанное 29 июн 20 в 02:15: EG> 28 июня 2020, воскресенье, в 18:19 NOVT, Ruslan Suleimanov написал(а): RS>> в локально запущенной вирутальной машине #sysctl -a | grep RS>> kern.disks тоже показывает только ada0 cd0 EG> Ты не понимаешь. Показания kern.disks имеют лишь косвенное EG> отношение к содержимому каталога /dev. Ядро монтирует EG> корневую файловую систему не по kern.disks, а по /dev. EG> "Дисковые" устройства в /dev кроме "корневых" типа da0 EG> нынче появляются после того как GEOM "обнюхает" диск: EG> прочитает и распарсит таблицу разделов, причём рекурсивно: EG> сначала парсит /dev/da0 и создаёт /dev/da0[sp]*, EG> затем снова парсит свежесозданный /dev/da0s1 (например) EG> и если находит там BSDlabel, то создаёт /dev/da0s1* и так EG> далее, пока вложенные структуры не кончатся. Я думал за структуру разделов отвечает MBR или GPT. Тоесть MBR или GPT получает уже готовые /dev/da0[sp]* или /dev/ada0[sp]* ? Я пробовал тот и тот вариант, не прошло... EG> Лишь потом ядро будет пытаться монтировать то, что насоздавал GEOM. EG> В твоём случае "структуры кончаются" прямо на самом da0, EG> потому что таблица разделов с него не прочиталась. EG>>> Очевидно, это потому что ядро не смогло прочитать таблицу EG>>> разделов, так что разделы оно не увидело и девайсы для них в EG>>> /dev не создало. Hадо бороться с исходной ошибкой чтения, без EG>>> этого ничего не будет. RS>> в ядре FreeBSD опция device da по умолчанию как и SCSI.. куда RS>> копать ? EG> В PR 215235 прямо сказано, что провайдеры облаков по мнению traz@ EG> криво реализуют стандарт SCSI, лишь бы работало с виндами и Linux, EG> и вроде как девелоперы AWS даже и не отпирались. Как обычно, EG> надо тестировать патч из старого PR (вдруг поможет) EG> и вообще продавливать доработку совместимости. Там патч 2017 года, думаешь будет работать ? EG> Можешь даже Ораклу завести тикет на тему нарушение стандарта SCSI :-) Добавил в критический тикет! Ждем! :-) WBR, Ruslan Suleimanov. Telegram: @rsuleimanov
From: Ruslan Suleimanov 2:467/888 28 Jun 2020 13:11 +0300
To: All
Subject: PV в OCI
Привет, All! Вот несколько дней пытаюсь поставить FreeBSD 12.1-RELEASE в Oracle Cloud, пробовал добавить образ в нескольких режимах: 1. EMULATED 2. PARAVILTUALIZED сразу скажу EMULATED режим у них второстепенный так имеет ряд недостатков по отношению к PV и все поддерживаемые OCI ОС почемуто в списке, а вот FreeBSD нет в списке, что не очень радует и я думаю не только меня.. После всех испытаний я понял, что запустить FreeBSD можно только в EMULATED где тип загрузочного тома будет: IDE, и этот режим нажаль в дорогущей опции от 1000$ (VM.Standard2.1)за клауд сервер... А хотелось бы всетаки запустить в VM.Standard.E2.1.Micro где 100Гб дискового пространства дается бесплатно.. вот загрузочный лог VM.Standard.E2.1.Micro в PARAVILTUALIZED (EMULATED не поддерживает): -- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247608 -- А вот сама вирутальная машина к которой можно подключится через консоль по следующему ключу id_rsa: -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn NhAAAAAwEAAQAAAQEAzJxyLiXTbeOUsneMqzozPWaMvQQbSERNYh5LF8jgAw0KrbzuqJWx USYdZo602G6jofTcoTUmWPuL5+MrnKMVmtrAULi0rUjdEIS0Bg5ZUpNdlGkxp2nvaCwE7F EmibtqqzU/oPzatr7GehOC/a34jnPPEjJVtRAZcNd8tl8KmZJgxhgzsLNc00ogHvJbW4Gq HulbjX38iAmCQu+f7OhmT6NrRlQGbQtXW4d6TJoy0LEVlpiaOCIGGeJpjGpZ1Ra9+IkaWP jxmTPq6PK5xmQIYmtkCWq9rdG1tvkls9EnOMvWxKQw7mD9kA4C3FgBLQQro7KYvx1O7OIU Ju6eRNO9MQAAA8i5aRZIuWkWSAAAAAdzc2gtcnNhAAABAQDMnHIuJdNt45Syd4yrOjM9Zo y9BBtIRE1iHksXyOADDQqtvO6olbFRJh1mjrTYbqOh9NyhNSZY+4vn4yucoxWa2sBQuLSt SN0QhLQGDllSk12UaTGnae9oLATsUSaJu2qrNT+g/Nq2vsZ6E4L9rfiOc88SMlW1EBlw13 y2XwqZkmDGGDOws1zTSiAe8ltbgaoe6VuNffyICYJC75/s6GZPo2tGVAZtC1dbh3pMmjLQ sRWWmJo4IgYZ4mmMalnVFr34iRpY+PGZM+ro8rnGZAhia2QJar2t0bW2+SWz0Sc4y9bEpD DuYP2QDgLcWAEtBCujspi/HU7s4hQm7p5E070xAAAAAwEAAQAAAQA/HNafY22HDNbWAcgz HL2nZ9VrjDO6I89Wv49cI8rtRf2QP6HCAIJ0THRvKP+hbucsUrInS5Srh9PM0CaopylH3c fKXl7kwH/n03cQEyb8MJaB67y0Lhn5oPJXzmQ7wcKSUtdwme4AxnHEP/Z8t0fe8NvjegEz 22ZthxphyokjexULURq2v4BAPbuC0ddFUrbwjQkOLXAEoFufGcqDTcucn0gFLleOOkdCwh y6q63NZgFB93VCDgTFjuNgK88iT7acJIYc7VIgQJsOHFpArwZ+lw2r8eQqpmx1JyPQ/pjg De6i9r4i1boedLFyhuoVqoDocCZStJaEJGuhcHZxHgJ9AAAAgQDAWCEzzHcD2yMES13Csn 1LYLcD8icliODk0j0DMN3fttsj8dvFNEPBFcuoOrvE4Y/BA4pdkNBAIfoILLv/oreXYprd 2CUS34YLPeqBJoZ0gFJ+i1ZM43KZsGPNExRVknQAdcCJPuAl/axk5qxe/uk38gQmXXAyv3 zy8a1G3CPOZQAAAIEA5dRHm7X1npsoC7T4i7D2IrKjut8ie09YIgevpwKMh8deZ/ebCGVD iXfVeeZVroEVL5y6hsxXoSciraihldcBfUF8LvcnKjHedupLCXmwbDqSogdDDSPwzCRfrA RuidOeTGs5MTMC4zg0EUdnu+EGR+PUm5SFNLmjf2GbAfEuZz8AAACBAOPpCXD9QjHEgyOD 1LryL0g21+zz7Sy6M5Hn7dog33Xl7tCFAg2wOYHEOIyHI0slMzxhxzB9pKVCvPyZ85qETy pnM/81P/QwP9g7md4nrn3UoCJn4HD4x/0RVPbXIcCN9T2lRQtJZQFa5J7b0ElkgGVqX2dr BC+EUb6TdINLrK+PAAAAEXJzckBmaWRvLnBha2V0LnVhAQ== -----END OPENSSH PRIVATE KEY----- #ssh -i id_rsa -o ProxyCommand='ssh -W %h:%p -p 443 ocid1.instanceconsoleconnection.oc1.eu-frankfurt-1.antheljtzemoauaceosvstn6ocxv4lrjvfmelnv6yrimwhauplw7oeno2uaa@instance-console.eu-frankfurt-1.oraclecloud.com' ocid1.instance.oc1.eu-frankfurt-1.antheljtzemoauackz75zpysah3u4l23ys2euxaqitmol43co42dxyogreua ---- Доходит до этапа: -- cut -- (da0:vtscsi0:0:0:1): SCSI status: Check Condition (da0:vtscsi0:0:0:1): Error 5, Retries exhausted mountroot: waiting for device /dev/ada0s1a... Mounting from ufs:/dev/ada0s1a failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/ada0s1a vfs.root.mountfrom.options=rw Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> и что потом только не пробовал... не хочется моунтится ни в какую... WBR, Ruslan Suleimanov. Telegram: @rsuleimanov
From: Victor Sudakov 2:5005/49 22 Jun 2020 20:22 +0300
To: Alex Korchmar <1187514068@ddt.demos.su>
Subject: git workflow
Dear Alex, 13 Jun 20 11:21, you wrote to me: VS>> И нафига мне всё это делать просто ради того, чтобы поменять 1 VS>> (один) commit message (даже не сам commit)? AK> message - точно такая же часть истории как и сам комит. В гите может и так (минус ему тогда), а по идее нет. Message - это метаданные. AK> В hg его поменять точно так же (на самом деле не так же, а совсем) С хрена ли? "hg histedit" и меняй на здоровье. Никакой rebase при этом не происходит. AK> невозможно. (кроме вырожденных случаев, нахер ненужных) Я так и живу с AK> "квадратиком" пятилетней давности. Если ты его уже запушил куда-то, может и не поменяешь, я не проверял. А пока changeset еще в фазе draft - меняй хоть по 5 раз на дню, никакие версии при этом лопатиться не будут. VS>> Даже если бы было так, как ты говоришь ниже (на самом деле нет) - VS>> какая разница в случае изменений commit message, а не содержимого VS>> коммита? AK> гит ничего не знает о том, что и зачем ты менял. Минус ему. Мог бы и отличать данные от метаданных. AK> Он создает новую историю, подменяя ей записанную - и где-то у тебя AK> попался либо забытый тобой мусор, либо еще что-то о чем ты забыл тут AK> сказать или сам не заметил. AK> Просто так конфликт не возник бы. Да дело даже не в том в конце концов, забыто там что-то мной или не забыто, а в том что для изменения commit message зачем-то понадобился rebase, зачем-то оно пошло всё переписывать... хотя мой коммит даже не покидал пределов моего личного репозитория. AK> ну и да, бэкапить супернадежную и супердистрибьютед vcs - таки надо AK> перед каждым неочевидным действием. Это тебе не svn, которую можно AK> разобрать и собрать обратно в любой момент. И commit message поменять svnadmin-ом в любой момент, без всяких совершенно проблем и ребейзов. Victor Sudakov, VAS4-RIPE, VAS47-RIPN
From: Eugene Grosbein grosbein.net 15 Jun 2020 17:01 +0300
To: Dmitry Ivanov 2:5023/24.3209
Subject: release/12.1.0
15 июня 2020, понедельник, в 11:23 NOVT, Dmitry Ivanov написал(а): DI> /usr/src# git branch DI> * release/12.1.0 DI> /usr/src# git log DI> Author: gjb DI> Date: Fri Nov 1 00:00:17 2019 +0000 DI> я что-то не умею в git, не туда смотрю или действительно нет никаких DI> изменений? В релизе и не должно быть никаких изменений. Когда проект FreeBSD использовал CVS, релиз был просто тегом на стабильной ветке или на HEAD, можешь считать это "снапшотом". Снапшоты неизменны по определению. При переходе на Subversion модель разработки не менялась. Релиз это всё ещё снапшот с девелоперской ветки плюс причёсанная документация, оформляж в виде образов, официальный анонс и всё такое прочее. Изменения вливаются в девелоперские ветки head и затем могут быть слиты в ветки stable и иногда в ветки releng, последнее в случае патчей безопасности. Hо релиз изменён быть не может, максимум он может быть перевыпущен, если в релизе уже после формирования и публикации итоговых образов обнаружилась серьёзная проблема (такое в истории было раз или два), но тогда создаётся новый релиз с .1 на конце. Eugene
From: Victor Sudakov 2:5005/49 12 Jun 2020 12:19 +0300
To: Alexey Fayans grosbein.net
Subject: git workflow
Dear Alexey, 12 Jun 20 13:38, Eugene Grosbein wrote to you: VS>>> Да, коммит был в master. Тут говорили, что так можно. AF>> Hу да, можно. Hо не без гемора. :) EG> А желание смешивать мух с котлетами это религизное? Я конечно сейчас сделаю git clone с нуля, приложу свой патчик с уже правильным commit message (а он приложится, потому что конкретно этот файл в апстриме никто не трогал). Но так и буду ходить вокруг гита как кот вокруг сметаны - бояться лишний раз тронуть что-нибудь. Victor Sudakov, VAS4-RIPE, VAS47-RIPN
From: Dmitriy Smirnov 2:5010/352@fidonet 08 Jun 2020 15:21 +0300
To: Eugene Subbotin <rbl76g$vd$1@news.dewy.ru>
Subject: конец арубы
hi, Eugene! 08 Jun 20 15:25, Eugene Subbotin wrote to Dmitriy Smirnov: DS>> до участкового дело может и не дойти, вдсина сама по себе без DS>> объяснений/предупреждений удаляет vps втихую и ладно если бы DS>> абьюзный. ES> Через 3 дня если не вносить оплату :) если бы, просто удалили. Ребята себе на уме, а сейчас еще запустили "веченые" серванты и где гарантия, что лавочку не свернут =) wbr, Dmitriy.
From: Eugene Subbotin <rbb0ej$pc8$3@news.dewy.ru> 04 Jun 2020 17:28 +0300
To: Andrey Ostanovsky 2:5030/1957
Subject: конец арубы
On 04.06.2020 12:11, Andrey Ostanovsky wrote: ES>> eurobyte.ru ES>> vdsina.ru AO> И автоматическая блокировка аккаунта по запросу от местного AO> участкового? :) В смысле? Блокировать имеет полномочия Роскомнадзор, а не хостинг. Они просто вносят IP адрес в реестр и всё.
From: Vladimir Donskoy 2:5020/2992 29 May 2020 22:14 +0300
To: Eugene Grosbein grosbein.net
Subject: Re^2: конец арубы
Hello Eugene! 29 май 20 08:37, Eugene Grosbein wrote to Vladimir Donskoy: VD>> И куды бечь? Что нонче "ФИДОрулез"? EG> Hetzner. Даже с учётом VAT примерно за ту же цену чуть менее 3 евро EG> дают виртуалку в KVM, почти 2G памяти и почти 20G диска: Спасибо! А как там с реальной нагруженностью (соседи мешают?) и нет ли подводных камней (траффик режут или порты фильтруют или ещё какая-то пакость)? Я пока сижу в virmach, но там соседи мешают жить, зато 25$ в год (а ещё и скидки есть, у меня 20% - итого 20$) за 1 Гиг и 20 гиг диска. С уважением, Vladimir Donskoy.