переусложнять тоже не нужно...здесь есть жители Киева ?

Но это надо ZFS учить. А через geom можно прямощас

так сейчас - это надо просто bdev c бекендом в nvdimm

так сейчас - это надо просто bdev c бекендом в nvdimm

Ну да.

зачем? можно же что-то наподобие линуксового dax. какой смысл тягать страницу в page cache, если она и так в памяти

кстати, а к линуксам как нибудь это более менее продакшен уже прилепили?

в смысле все вот эти новые интел и около выкрутасы памяти

кстати, а к линуксам как нибудь это более менее продакшен уже прилепили?

вживую я нигде не видел =( вроде у hp были продукты. собственно, о nvdimm и pmem я узнал когда этот dax втаскивали.

вообще странно, интел же на это деньжишь и даже кого то командировало и что то тишина, вот теперь откуда не ждали внезапно :)

На хабре же были статьи про кингстон кажется - они там топят за свой супер софт для винды - онли который умнейшим образом кэширует ее потроха и на порядки порядков всё ускоряет. А на generic применение они клали.

ой от кингстона, там очень уж маркетенговый булшит

из наркомании, что я тут недавно видел - это p2p dma.

Я думаю, в HP И Orracle для своих баз сделают поддержку

Эти также небось. Специализированные примочки для оракала и мсскл каких нибудь, остальное не сильно интересно

https://www.snia.org/sites/default/files/SDC/2018/presentations/Storage_Architecture/Bates_Stephen_Accelerating_Storage_with_NVM_Express_SSDs_and_P2PDMA.pdf

Эти также небось. Специализированные примочки для оракала и мсскл каких нибудь, остальное не сильно интересно

разумеется

ой от кингстона, там очень уж маркетенговый булшит

Так и есть, и позиционирование технологии сразу становится понятно

а вот вопрос про нетфликсовский OCA

там они писали про tls

Так и есть, и позиционирование технологии сразу становится понятно

ну а чего не так с технологией то, такое себе промежуточное хранилище, потолше оперативы, пошустрее SSD чем плохо то?

Ничем. Но поддержка её при таком подходе появится только руками энтузиастов неизвестно как, когда и насколько, учитывая что через год они могут выпустить новое несовместимое поколение

и сколько сил они в него вложили, вместо того чтобы взять тот же mlx5 у которого tls сделан в железе

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

Особенно актуально для жителей Питера, ну или гостей. В последнюю среду октября (31-го) проводится собрание http://spblug.org/ (оно в принципе проходит каждый месяц) Но в этот раз, ко всему прочему, я расскажу что нового планируется во FreeBSD-12, можно это пообсуждать, там очень даже душевная атмосфера, предусмотрен чай и всё такое. Так же высока вероятна трансляции и запись, но это приятный довесок. UPD официальный анонс, адрес и такое https://groups.google.com/forum/#!topic/spblinux/dGK9UNMx3d4

Так можен запинить? Надо конечно и в мск огранизовать встречу)

опять всех напугал :) я токо добрался до откуда можно пинить :)

Особенно актуально для жителей Питера, ну или гостей. В последнюю среду октября (31-го) проводится собрание http://spblug.org/ (оно в принципе проходит каждый месяц) Но в этот раз, ко всему прочему, я расскажу что нового планируется во FreeBSD-12, можно это пообсуждать, там очень даже душевная атмосфера, предусмотрен чай и всё такое. Так же высока вероятна трансляции и запись, но это приятный довесок. UPD официальный анонс, адрес и такое https://groups.google.com/forum/#!topic/spblinux/dGK9UNMx3d4

планирую быть. там никакой регистрации предварительной не требуется?

не, там всё демократично, раньше указанного особо лучше не приходить, там никого может не быть, но к сколько там указано, часикам к 7ми вроде, всегда кто то подходит, на охране пароль в Феникс, если спрашивают куда

не, там всё демократично, раньше указанного особо лучше не приходить, там никого может не быть, но к сколько там указано, часикам к 7ми вроде, всегда кто то подходит, на охране пароль в Феникс, если спрашивают куда

спасибо!

если что тут есть чятик https://t.me/spblug_chat можно туда шуметь

Воть.

Через две недели, 31 числа, состоится очередное собрание SPbLUG. И раз уж это день всяческой нечистой силы, то мы будем погружаться в мир чертей и демонов: Андрей Фесенко расскажет нам он новинках, ожидаемых в 12 релизе операционной системы FreeBSD. Встреча состоится как обычно в ЦДО Феникс, расположенном внутри здания географического ф-та СПбГУ по адресу 10я линия В.О. 33/35 (большая белая дверь на первом этаже напротив входной лестницы). Всречаемся в 19, расходимся в 22. Начало доклада около восьми вечера.

ну да, я ссылку на письмо в припиненый пост добавил

Deleting libssh-0.7.5.txz: new version: 0.8.4 :)))

О как

А теперь мы на всей это хрени попытаемся взлететь :-)

Move the rc framework out of sbin/init into libexec/rc да они издеваются что ли?

OpenRC же из генты притащат

и делать это надо прямо вот щяс?

это если что нынче в svnlog

и?

ну как бы заморозка, релиз там всё вот это

Чё то я очкую :-)

Апгрейдится

Свои 100500 серваков

не сцы, make install на все сразу и понеслась :)

ггг

глаза боятся, а руки make’ают

Life is what you make it :-D

/me словил кернел паник, связанный с if_em kernel: Fatal trap 18: integer divide fault while in kernel mode kernel: cpuid = 4; apic id = 04 kernel: instruction pointer = 0x20:0xffffffff818602e4 kernel: stack pointer = 0x28:0xfffffe07eb0f4400 kernel: frame pointer = 0x28:0xfffffe07eb0f4410 kernel: code segment = base 0x0, limit 0xfffff, type 0x1b kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 kernel: current process = 0 (em0 que) kernel: trap number = 18 kernel: panic: integer divide fault kernel: cpuid = 4

система FreeBSD 11.2-STABLE #0 r339018: Sat Sep 29 22:26:16 EEST 2018

опция options EM_MULTIQUEUE присутствует в ядре

OpenRC же из генты притащат

Серьезно?

Серьезно?

есть такие планы, таки пойдут ли на это и в каком мажорном релизе, пока неясно

как пионеры это обкатали в TrueOS

OpenRC же из генты притащат

Вряд ли

т.е. с принятием решения - портируют легко, уже готовое, считай

ldd /usr/sbin/sshd /usr/sbin/sshd: libssh.so.5 => /usr/lib/libssh.so.5 (0x800685000) libutil.so.8 => /lib/libutil.so.8 (0x8007d8000) libz.so.5 => /lib/libz.so.5 (0x8008e9000) libwrap.so.6 => /usr/lib/libwrap.so.6 (0x8009fe000) libpam.so.5 => /usr/lib/libpam.so.5 (0x800b07000) libbsm.so.3 => /usr/lib/libbsm.so.3 (0x800c0f000) libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x800d2a000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800e44000) libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x800f4e000) libasn1.so.10 => /usr/lib/libasn1.so.10 (0x8010bd000) libcrypto.so.6 => /lib/libcrypto.so.6 (0x80123f000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x8014e0000) libc.so.7 => /lib/libc.so.7 (0x801600000) libhx509.so.10 => /usr/lib/libhx509.so.10 (0x801843000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x801983000) libmd.so.5 => /lib/libmd.so.5 (0x801a85000) libroken.so.10 => /usr/lib/libroken.so.10 (0x801b95000)

Я вижу libssh.so. Я правильно понимаю что это означает подверженность сервера уязвимости бибилиотеки libssh?

Move the rc framework out of sbin/init into libexec/rc да они издеваются что ли?

Они там дальше пишут что так будет удобнее "системди" устанавливать: * having rc in its own place will allow more easy replacement of the rc framework with alternatives, such as openrc.

ЗЫ я про это: https://www.opennet.ru/opennews/art.shtml?num=49453

ЗЫ я про это: https://www.opennet.ru/opennews/art.shtml?num=49453

наверно, достаточно подписаться на FreeBSD-security@FreeBSD.org

наверно, достаточно подписаться на FreeBSD-security@FreeBSD.org

Так вроде уже обновили

См чат выше

ну так писем нет

https://www.freebsd.org/security/advisories.html

в адвизорисах тож тишина, значит не аффектед

наверно, достаточно подписаться на FreeBSD-security@FreeBSD.org

А как это сделать? На https://www.freebsd.org/ru/security/ я не нашёл...

ERROR: S client not available

https://lists.freebsd.org/mailman/listinfo/freebsd-security

взято из хэндбука https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

вру

FreeBSD Security Advisories<security-advisories@freebsd.org>

сюда подписаться

libssh -- authentication bypass vulnerability VuXML ID: 2383767c-d224-11e8-9623-a4badb2f4699 Discovery: 2018-10-16 Entry: 2018-10-17 Packages 0.6 <= libssh < 0.7.6 0.8 <= libssh < 0.8.4 Description gladiac reports: libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authentciate without any credentials. URL https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/

ну да, но порты как бы на совести сисадмина

их актуальность в системе

Спасибо

/me словил кернел паник, связанный с if_em kernel: Fatal trap 18: integer divide fault while in kernel mode kernel: cpuid = 4; apic id = 04 kernel: instruction pointer = 0x20:0xffffffff818602e4 kernel: stack pointer = 0x28:0xfffffe07eb0f4400 kernel: frame pointer = 0x28:0xfffffe07eb0f4410 kernel: code segment = base 0x0, limit 0xfffff, type 0x1b kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 kernel: current process = 0 (em0 que) kernel: trap number = 18 kernel: panic: integer divide fault kernel: cpuid = 4

ну так в багзиллу и всю интеловскую братию в CC: в добавок к net@. Если их пинать (а особенно если их пинать крешдампами) они, в общем, реагируют.

т.е. собирать ядро с дебаг опциями и ждать нового паника?

Ну, сначала можно просто крешдампы включить. Если есть возможность, то неплохо и INVARIANTS.

Вообще, ядро всегда должно быть с дебаг-опциями (теми, что про символы и крешдампы, я не про IMVATIANTS и WITNESS, понятно, что последние прилично тормозят систему).

т.е. собирать ядро с дебаг опциями и ждать нового паника?

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

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options KDB # Enable kernel debugger support. options KDB_TRACE # Print a stack trace for a panic.эти опции или еще что-то?

А какая нужна? Понятно, что это app specific. И нужна поддержка в приложениях потому что это не существовавший до того концепт — память, которая persistent

Вот у NetApp-а NVRAM нечто похожее :-)

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options KDB # Enable kernel debugger support. options KDB_TRACE # Print a stack trace for a panic.эти опции или еще что-то?

ну, необходимый минимум есть, надо ещё dumpdev или как его там в rc.conf

dumpdev по дефолту отрабатывает

а крэшдампа нет при этом?

крешдамп есть

но без отладочтных символов - бесполезен

# kgdb /boot/kernel/kernel /var/crash/vmcore.3 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xffffffff806b819b in doadump () (kgdb) bt #0 0xffffffff806b819b in doadump () #1 0xffffffff806b81c5 in doadump () #2 0xfffffe07eb0f4120 in ?? () #3 0xffffffff806b8016 in kern_reboot () Previous frame identical to this frame (corrupt stack?)

но без отладочтных символов - бесполезен

так в 11 символы же по умолчанию ставятся

но вообще и правда похоже на порушенный стек, символы тут особо не при чём

/me словил кернел паник, связанный с if_em kernel: Fatal trap 18: integer divide fault while in kernel mode kernel: cpuid = 4; apic id = 04 kernel: instruction pointer = 0x20:0xffffffff818602e4 kernel: stack pointer = 0x28:0xfffffe07eb0f4400 kernel: frame pointer = 0x28:0xfffffe07eb0f4410 kernel: code segment = base 0x0, limit 0xfffff, type 0x1b kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 kernel: current process = 0 (em0 que) kernel: trap number = 18 kernel: panic: integer divide fault kernel: cpuid = 4

на работающей системе запустите kgdb и сделайте там list *0xffffffff818602e4

при паниках от деления на ноль, 95% решения проблемы в том, чтобы найти место где это деление происходит

(kgdb) list *0xffffffff818602e4 No symbol table is loaded. Use the "file" command.

я жду след паника, далее по соглосованию с клиентом, добавляю дебаг в ядро и ждем следующих паников

я не знаю, зачем вообще убирать его из ядра, оно ни на что не влияет

только лишний гемор себе создаёте

Мы вот боимся RCU из-за патентов, а там всёрьёз говорят что бы добавить его в C++ stdlib :-)

наличие RCU не перепишет весь код автоматически