Проект выглядел заброшенным и неподдерживаемым. Перечитал эху с 2010.
Цель релиза - собрать полезные фиксы и фичи из разрозненных форков и вернуть сборку на современных тулчейнах.
Дальше больше: появились несколько удобных фич, которых не хватало :)
Из заметного: share (shared AKA как в binkd, failover нетмейла), rootdomain, интернет-флаги нодлиста INA/IBN/IFC, плюс фиксы для переносимости. Полный лог на гитхабе.
Сборка и живые тесты проведены на Debian 12/13, Ubuntu 24.04, Fedora
44, Alpine 3.20 (musl), RPi OS (aarch64). Сборка также на FreeBSD
15.1, NetBSD 11, OpenBSD 7.9.
Репозиторий: https://github.com/glasslike/qico
Как собрать: https://github.com/glasslike/qico/blob/master/BUILD.md
Может быть, что-то еще добавить, со временем? ;)
Репозиторий: https://github.com/glasslike/qico
Может быть, что-то еще добавить, со временем? ;)
Спасибо, вот это дельная задача! qcc работает нормально везде?
Есть ещё смысл ещё обновить реализацию binkp исходя из https://github.com/pgul/binkd
Спасибо, вот это дельная задача! qcc работает нормально везде?
Да, qcc сейчас без проблем, но проверял только на своем хосте Debian
12 (aarch64). В целом, все замеченные косяки поправил и сам пока
пользуюсь с удовольствием. Binkd хорош, но qico - комбайн, нельзя забрасывать такой :)
Да, qcc сейчас без проблем, но проверял только на своем хосте
Debian 12 (aarch64). В целом, все замеченные косяки поправил и
сам пока пользуюсь с удовольствием. Binkd хорош, но qico -
комбайн, нельзя забрасывать такой :)
а NetBSD qcc виснет, как раньше. Возможно связано с тем, что там не ncurses, а родной системный curses.
Да, qcc сейчас без проблем, но проверял только на своем хосте
Debian 12 (aarch64). В целом, все замеченные косяки поправил и
сам пока пользуюсь с удовольствием. Binkd хорош, но qico -
комбайн, нельзя забрасывать такой :)
а NetBSD qcc виснет, как раньше. Возможно связано с тем, что там
не ncurses, а родной системный curses.
да, qcc на NetBSD по-прежнему с libcurses.
нужно поставить ncurses, и попробовать вот так:
export CPPFLAGS="-I/usr/pkg/include"
export LDFLAGS="-L/usr/pkg/lib -Wl,-R/usr/pkg/lib"
./autogen.sh
./configure -blablabla
и в логе что-то такое смотреть:
checking for main in -lncurses... yes
checking for ncurses.h... yes
checking for qcc support... yes
..
gmake
у меня нет продакшен BSD, но попробую собрать, проверить..
Binkd хорош, но qico - комбайн, нельзя забрасывать такой :)
Binkd хорош, но qico - комбайн, нельзя забрасывать такой :)Там очень плохо все в модемной части, большую часть надо переписывать.
у меня нет продакшен BSD, но попробую собрать, проверить..Ага, спасибо. И неплохо было бы научить работе с curses BSD-шным,
чтобы оно не висло :)
у меня нет продакшен BSD, но попробую собрать, проверить..
Binkd хорош, но qico - комбайн, нельзя забрасывать такой :)Там очень плохо все в модемной части, большую часть надо переписывать.
Ага, спасибо. И неплохо было бы научить работе с curses BSD-шным, чтобы оно не висло :)
Binkd хорош, но qico - комбайн, нельзя забрасывать такой :)
Там очень плохо все в модемной части, большую часть надо
переписывать.
Там этих форков я помню было, один вроде даже рабочий. о если
перечитали архив эхи я думаю контекста достаточно.
Ага, спасибо. И неплохо было бы научить работе с curses BSD-шным,
чтобы оно не висло :)
Если че на BSD можно мне потестить будет, плюс я вроде там мейнтейнер, можно и порт обновить будет, а то щас там на какой-то форк ссылается.
Если текущий рабочий можно переключиться будет.
Там этих форков я помню было, один вроде даже рабочий. о если
перечитали архив эхи я думаю контекста достаточно.
Это было бы здорово! Могу добавить контрибьютором в репо?
Да, там было много форков, я перпелопатил все, что нашел (указал их в https://github.com/glasslike/qico/blob/master/README также):
https://github.com/askovpen/qico
https://github.com/evs38/qico
https://github.com/leenooks/qico
https://github.com/uncleeugene/qico
https://github.com/kosfango/qico
+ cvs + репо RJ Clay
у и перечитал всю эту эху, чтобы понять, как вообще всё развилось до сегодняшнего :)
Да, там было много форков, я перпелопатил все, что нашел (указал
их в https://github.com/glasslike/qico/blob/master/README также):
https://github.com/askovpen/qico
https://github.com/evs38/qico
https://github.com/leenooks/qico
https://github.com/uncleeugene/qico
https://github.com/kosfango/qico
+ cvs + репо RJ Clay
у и перечитал всю эту эху, чтобы понять, как вообще всё развилось
до сегодняшнего :)
Был ещё какой то репо, ща вспомню, но он тут отсвечивал
Да, там было много форков, я перпелопатил все, что нашел (указал их в https://github.com/glasslike/qico/blob/master/README также):
https://github.com/askovpen/qico
https://github.com/evs38/qico
https://github.com/leenooks/qico
https://github.com/uncleeugene/qico
https://github.com/kosfango/qico
+ cvs + репо RJ Clay
https://icelan.ru/svn/qicoxe/trunk/Кто-то ваще сбоку пилит.
https://icelan.ru/svn/gentoo-overlays/qico-xe/
Я ничё сбоку не пилю :) Я взял последние известные мне сорцы оригинального qico-xe (всмысле именно этого оригинального форка), наложил на них известные мне последние патчи от автора, не попавшие в релизы, и засунул в свою репу,
потому что больше было некуда и у меня всё работало.
За версиями и развитием других форков не слежу, в этом ничё не правлю кроме gentoo ebuild, да и тот актуальная версия в отдельной репе уже.
Вот относительно недавно наконец-то переехал с x86 на x64, та же версия qico-xe по-прежнему собирается и работает.
Вполне возможно, что я там патчил что-то для фикса компиляции когда-нибудь давно, но это маловероятно, большинство фиксов, которые я не могу проверить сборкой на других системах, я делаю исключительно патчами в gentoo ebuild.
А идти в history и проверять мне лень :)
Да, там было много форков, я перпелопатил все, что нашел (указал
их в https://github.com/glasslike/qico/blob/master/README также):
https://github.com/askovpen/qico
https://github.com/evs38/qico
https://github.com/leenooks/qico
https://github.com/uncleeugene/qico
https://github.com/kosfango/qico
+ cvs + репо RJ Clay
у и перечитал всю эту эху, чтобы понять, как вообще всё развилось
до сегодняшнего :)
Был ещё какой то репо, ща вспомню, но он тут отсвечивалГут. Если есть - присылай, я тоже проверю, есть ли там что-то дельное, перенесу, если не устарело уже.
Hello, Alexey!
кажется ты упустил это
https://icelan.ru/svn/qicoxe/trunk/
https://icelan.ru/svn/gentoo-overlays/qico-xe/
в общем там куча форков и как все смержить, только на ИИ надежда )
Гут. Если есть - присылай, я тоже проверю, есть ли там что-то
дельное, перенесу, если не устарело уже.
Я полистал архив эхи, это не так и давно было, много всяких фиксов, пилителей и тп. Там даже чет обсуждения были, баги, фиксы, как
собрать все патчи в нормальный реп.
о сейчас наверно жпт справится без проблем.
Всё верно, svn на icelan тоже проверял. Там ничего нового - старые фиксы по переносимости, но уже не актуальны. Всё уже было перенесено в какой-то из форков на гитхабе.https://icelan.ru/svn/qicoxe/trunk/
https://icelan.ru/svn/gentoo-overlays/qico-xe/
Единственное - не видел того, который gentoo. Посмотрю тоже, спасибо :)
в общем там куча форков и как все смержить, только на ИИ надежда )адо смержить. Скорее всего не буквально, а по смыслу. Ибо во многих местах код уже был исправлен. Поэтому моя идея была - собрать всё вместе, чтобы не плодить кучу форков, которые потом сложно мержить :
Выпущен qico 0.60.0
Может быть, что-то еще добавить, со временем? ;)
Еще проблема протестить модемную часть, это прям будет сложно, хотя реально, надо просто чтобы на другом конце был мылер который все
умеет. Кстати помню недавно пилили же Bforce, вроде как это тоже
комбаин похлеще qico
Выпущен qico 0.60.0
Может быть, что-то еще добавить, со временем? ;)
Предлагаю добавить сохранение бинарных логов в одном из форматов, поддерживаемых моей утилитой T-Hist.
Предлагаю добавить сохранение бинарных логов в одном из форматов,
поддерживаемых моей утилитой T-Hist.
Да, я как раз на днях хотел протестить T-Hist, но не нашел исходников, чтобы собрать себе на aarch64 (писал об этом в локалке /715). Хорошая
идея - иметь возможность сохранения нормальных бинарных логов, можно сделать. О формате надо порассуждать.
Было бы здорово, чтобы кто-нибудь, у кого есть реальная телефонная линия и модем, протестили бы модемную часть!
К сожалению, у меня сейчас нет ни медной линии (в Швеции с этим проблема), ни модема - пока тестирую на простом эмуляторе hayes модема, который позволяет мейлеру получать ответ на все AT-команды, законнектиться, EMSI и т.д.
Мне не очень хочется выкладывать исходники, потому что просто стыдно
за такой код.
T-Hist я начал делать в 1996 году, и куски кода есть с
тех времён, когда я вообще не думал о какой-то культуре ведения кода, структурировании (всё свалено в один файл) и т.п. Там в коде даже один goto есть, и трогать я его не буду, потому что оно работает :).
23 года я в исходники не заглядывал - с 2003 года, когда была сделана последняя версия под DOS, OS/2, NT. А тут вот летом перенёс ноду под линукс, и встал вопрос о генерации статистики. Полез я в старый код - кровь из глаз.
Всё-таки довёл более-менее до чего-то работающего. Спасибо /715,
который стал тестером новых версий. а его хорошо загруженном узле
легче было баги вылавливать, чем у меня с одним единственным аплинком.
Может быть, что-то еще добавить, со временем? ;)Авто-тоссинг по завершении сессии починил? :)
Авто-тоссинг по завершении сессии починил? :)
У меня почта тоссится по крону, т.к. *не всегда* кика запускает скрипт тоссера.
Предлагаю добавить сохранение бинарных логов в одном из форматов, поддерживаемых моей утилитой T-Hist.
а выбор предлагается три формата:
3. Собственный формат T-Hist - большой размер записей (256 байт); 64-битные значения для трафика, позволяющие корректно сохранять
информацию о сессиях, во время которых было передно или получено более
4 гигабайт; отметка парольных/непарольных сессий; размер текстовой информации - до 206 символов.
В настоящее время я работаю над второй версией формата T-Hist. В ней
будут записи переменной длины: от 50 до 256 байт в зависимости от
размера текстовой информации. Если текст не сохранять, то размер
записей будет не намного больше, чем у Binkd, но с 64-битными
величинами для трафика.
2. Формат T-Mail версий 2603 и новее - средний размер записей (100
байт); можно отмечать парольные/непарольные сессии; можно сохранить до
63 символов текстовой информации (например, имя узла, локацию,
ip-адрес и т.д.); те же самые проблемы с записью информации от
величине трафика из-за 32-битных величин.
Формат "T-Hist v1 (256 байт)" - этот формат, наверное, наиболее
оптимален. Можно взять его, и не ждать v2. Или есть смысл подождать, и потом не переделывать? :)
Было бы здорово, чтобы кто-нибудь, у кого есть реальная телефонная линия и модем, протестили бы модемную часть!
К сожалению, у меня сейчас нет ни медной линии (в Швеции с этим проблема), ни модема - пока тестирую на простом эмуляторе hayes модема, который позволяет мейлеру получать ответ на все AT-команды, законнектиться, EMSI и т.д.
Bforce - интересно, надо попробовать тоже.
Кстати ИИ анализ фич сказал что Bforce умеет ipv6, а qico - нет, вот
уже есть первая фича реквест, если конечно ИИ не соврал
│23 Sep 23:19:53: connecting to 2:5020/1042 at f1042.n5020.z2.binkp.net:24556
│23 Sep 23:19:53: TCP/IP connection with 2001:470:dcd0:0:f1d0:2:5020:1042:2455
│23 Sep 23:19:53: starting outbound Binkp session
│23 Sep 23:19:53: address: 2:5020/1042@fidonet
ЧЯДТ? Лог из "моего" qico-xe (того, что на svn.icelan.ru)
https://github.com/glasslike/qico/blob/master/README также):
https://github.com/askovpen/qico
https://github.com/evs38/qico
https://github.com/leenooks/qico
https://github.com/uncleeugene/qico
https://github.com/kosfango/qico
Я полистал архив эхи, это не так и давно было, много всяких фиксов,
Кстати ИИ анализ фич сказал что Bforce умеет ipv6, а qico - нет,
вот уже есть первая фича реквест, если конечно ИИ не соврал
Там ещё были мои фиксы. Причём я, по меркам ИИ, не смог
протестировать, а только собрать.
Я в СС поставил ru.ai, чтобы ещё раз напомнить, что всё это poison, отравлено, что после .. года вливается в гитхабы.
А ты какого лжеца использовал? ;)
А ты какого лжеца использовал? ;)
Обычного гуглового... у он там мне начал оправдываться
1. Входящие соединения (Dial-in) - Работает без патчей. В режиме
приема почты qico может работать по IPv6 вообще без изменения
исходного кода.
Это происходит за счет архитектуры Unix-систем: мейлер
регистрируется в системном суперсервере xinetd (или inetd), который слушает порты.
Если xinetd настроен на IPv6, он принимает входящий сетевой вызов
от удаленной ноды и прозрачно перенаправляет поток данных в qico.
Сам мейлер при этом даже "не знает", что работает по IPv6, для него
это обычный стандартный ввод-вывод (через сокет). В таком сценарии
все работает "из коробки".
2. Исходящие соединения (Dial-out) - ужен патчПроблема
оригинального "ванильного" кода qico (включая ветку qico-xe)
заключалась в том,
что его внутренний встроенный сетевой клиент для Binkp изначально
был жестко написан под IPv4 (использовал старые структуры сокетов). Поэтому для того, чтобы qico мог сам звонить на IPv6-адреса, сисопы используют сторонние исправления.
Самое известное из них - qico-0.57.1xe-ipv6.patch (автор André Grüneberg). Этот патч переводит сетевую подсистему qico на использование современных
системных вызовов getaddrinfo, после чего мейлер начинает нативно совершать исходящие вызовы по IPv6.
Всё верно.
В частности, как простой пример, смотри юниты systemd для debian: github.com/glasslike/qico/tree/master/systemd
Юнит qico-binkp.socket, например.
2. Исходящие соединения (Dial-out) - ужен патчПроблема
оригинального "ванильного" кода qico (включая ветку qico-xe)
заключалась в том,
что его внутренний встроенный сетевой клиент для Binkp изначально
был жестко написан под IPv4 (использовал старые структуры сокетов).
Поэтому для того, чтобы qico мог сам звонить на IPv6-адреса, сисопы
используют сторонние исправления.
Самое известное из них - qico-0.57.1xe-ipv6.patch (автор André
Grüneberg). Этот патч переводит сетевую подсистему qico на
использование современных
системных вызовов getaddrinfo, после чего мейлер начинает нативно
совершать исходящие вызовы по IPv6.
Это уже было в актуальном репозитории, если верить changelog'у - было сделано еще в 0.57.2xe, соответственно, есть и у нас.
github.com/glasslike/gico/blob/master/Changes (line 77)
Работоспособность лучше проверить реальным тестом.
Всё верно.
В частности, как простой пример, смотри юниты systemd для debian:
github.com/glasslike/qico/tree/master/systemd
Юнит qico-binkp.socket, например.
Ага, но вообще юзать inetd хз, ну такое, костыль какой-то,
перекладывание головняка с одной головы на другую, хотя
пользователей ipv6 1-2шт.
В текущей схеме не используется классический inetd. Или в чем именно костыль? :) И как у тебя реализован механизм управления входящими?
Там ещё были мои фиксы.В каком репо?
Я прошерстил все, и забрал все фиксы, которые актуальны и корректны.
Там ещё были мои фиксы.
В каком репо?Я в эту эху прямо постил патчи. Тогда современным GCC не собиралось, и
я туда-сюда поправить две минуты буквально. Сегодня с ИИшкой - это две секунды уже :-)
Я прошерстил все, и забрал все фиксы, которые актуальны иПрикольно. Мне всегда симпатично, когда-то кто-то берёт лидерство над давнишним проектом, собирая разросшиеся вокруг ветки, и поддерживает
корректны.
это, хотя бы следующие 2-3 года, когда запал заканчивается ;-) о
потом, лет через 5-10, работу подхватит следующий, и ещё года три протолкает вперёд ;-)
Предлагаю добавить сохранение бинарных логов в одном из форматов, поддерживаемых моей утилитой T-Hist. https://github.com/klug378/T-Hist/blob/main/ADD-NEW-MAILER-ru.md
3. Собственный формат T-Hist - большой размер записей (256 байт);
В ветке dev реализована поддержка бинарного лога в формате T-Hist v1.
Предлагаю обсудить возможность добавления в T-Hist поддержку
следующего:
- Флаг L (listed) и причина обрыва - сейчас никуда не пишутся. Было бы здорово иметь и эту информацию. L можно писать в spare bit 4,
например.
Причину обрыва - вопрос. - Кроме того, можно подумать о
записи сессии в failed даже если она оборвалась до хэндшейка.
апример, в своем анализаторе лога binkd я вывожу такую информацию отдельной табличкой, и туда порой попадают всякие сканеры и боты
(иногда полезно знать).
- Можно ли добавить опцию перевода всех величин в Kb/Mb/Gb? (в т.ч. и Total Received/Sent/Traffic)
- Можно ли добавить опцию перевода всех величин в Kb/Mb/Gb? (в
т.ч. и Total Received/Sent/Traffic)
У меня оно всё на самом деле в KiB, MiB, GiB, чтобы вычислять обычными битовыми сдвигами. А однобуквенные обозначения тянутся с прошлого века
и запихивания всего в 80 символов в строке.
- Можно ли добавить опцию перевода всех величин в Kb/Mb/Gb? (в
т.ч. и Total Received/Sent/Traffic)
У меня оно всё на самом деле в KiB, MiB, GiB, чтобы вычислять
обычными битовыми сдвигами. А однобуквенные обозначения тянутся с
прошлого века и запихивания всего в 80 символов в строке.
А, кажется, сообразил. Можно оставить в таблицах однобуквенные
обозначения 'K', 'M', 'G', а после таблиц выводить расшифровку: либо
это KiB, MiB, GiB, либо KB, MB, GB.
В ветке dev реализована поддержка бинарного лога в формате T-HistЯ отправил в AFTNMISC версию T-Hist 1.5.0 с поддержкой второй версии формата. Структура записи второй версии точно такая же, как у первой,
v1.
но без записи в лог хвоста нулей. Подробнее в файле
ADD-NEW-MAILER-ru.md в архиве с T-Hist и на гитхабе: https://github.com/klug378/T-Hist/blob/main/ADD-NEW-MAILER-ru.md
Также сделал новую утилиту: конвертер форматов бинарных логов
HistConv. Позволяет для бинарного лога любого поддерживаемого T-Hist мейлера создать такой же лог в одном из следующих форматов: T-Hist
первой и второй версии, старый и новый форматы T-Mail, формат Binkd
(он же старый формат T-Mail, но с особенностями).
- Флаг L (listed) и причина обрыва - сейчас никуда не пишутся.Да, вполне можно - в статусе сессии используются только биты 0, 1, 2,
Было бы здорово иметь и эту информацию. L можно писать в spare
bit 4, например.
3. ачиная с 4-го можно занимать. адо только будет понять, как в
T-Hist отображать. То ли в виде какой-то односимвольной отметки
(например, 'L') в самих таблицах, то ли в виде слова "Listed" справа
от сроки таблицы в режиме широкого экрана.
Причину обрыва - вопрос. - Кроме того, можно подумать оу в текстовую информацию, отображаемую T-Hist, можно до 205 символов запихнуть.
записи сессии в failed даже если она оборвалась до хэндшейка.
апример, в своем анализаторе лога binkd я вывожу такую
информацию отдельной табличкой, и туда порой попадают всякие
сканеры и боты (иногда полезно знать).
Если handshake прошёл, а причина не из этого списка - failed. Как
лучше - зависит от того, как ты обрабатываешь строки в T-Hist. Просто выводишь в определенном порядке справа в широком режиме, или
используешь где-то еще, и поэтому порядок важен?
Если handshake прошёл, а причина не из этого списка - failed. Как
лучше - зависит от того, как ты обрабатываешь строки в T-Hist.
Просто выводишь в определенном порядке справа в широком режиме,
или используешь где-то еще, и поэтому порядок важен?
Формат с 5 строками сделан "на вырост". Сам T-Hist сейчас при
обработке просто тупо склеивает все непустые строки в одну строку, вставляя для разделения "; ".
И еще. При выводе статистики по сессиям выводится текст из конкретной обрабатываемой записи. А вот в статистике по линкам и на график -
текст из первой встреченной для данного узла записи. Потому что
записей для этого узла может быть много, и выбрать нужно что-то одно.
А вообще можно для qico персональный вариант формата разработать.
Версия формата определяется пятым байтом сигнатуры. Сделать версию 3, вставить, если нужно, дополнительные поля, разместить строки как надо.
у или не менять структуру, но просто сделать соглашение для формата,
какая строка что означает и когда её нужно выводить, а когда не нужно.
И еще. При выводе статистики по сессиям выводится текст из
конкретной обрабатываемой записи. А вот в статистике по линкам и
на график - текст из первой встреченной для данного узла записи.
Потому что записей для этого узла может быть много, и выбрать
нужно что-то одно.
Из первой встреченной ok-сессии? Тогда - не станет проблемой.
Imho, персональный формат не нужен - не вижу ничего такого, что кардинально отличало бы объем данных лога qico от остальных мейлеров. Вопросы только в маппинге, как раз их и обсуждаем. Когда перейдем на
v2 формата, и наверное, v1 станет и не нужна, так?
- Флаг L (listed) и причина обрыва - сейчас никуда не пишутся.
Было бы здорово иметь и эту информацию. L можно писать в spare
bit 4, например.
Да, вполне можно - в статусе сессии используются только биты 0, 1, 2,
3. ачиная с 4-го можно занимать. адо только будет понять, как в
T-Hist отображать. То ли в виде какой-то односимвольной отметки
(например, 'L') в самих таблицах, то ли в виде слова "Listed" справа
от сроки таблицы в режиме широкого экрана.
И еще. При выводе статистики по сессиям выводится текст из
конкретной обрабатываемой записи. А вот в статистике по линкам и
на график - текст из первой встреченной для данного узла записи.
Потому что записей для этого узла может быть много, и выбрать
нужно что-то одно.
Из первой встреченной ok-сессии? Тогда - не станет проблемой.
Я как-то не задумывался об этом, и сейчас берёт просто из самой
первой. о действительно стоит сделать так, чтобы брал из первой
ok-сессии. Сделаю в следующих версиях.
Imho, персональный формат не нужен - не вижу ничего такого, что
кардинально отличало бы объем данных лога qico от остальных
мейлеров. Вопросы только в маппинге, как раз их и обсуждаем.
Когда перейдем на v2 формата, и наверное, v1 станет и не нужна,
так?
Откатывать я, конечно, уже не буду, раз уж первая версия была
реализована. о да, при наличии второй версии в первой особого смысла
нет. Просто идея записей переменной длины мне пришла в голову, когда первая версия уже ушла в "продакшен" :)
у меня нет продакшен BSD, но попробую собрать, проверить..Ага, спасибо. И неплохо было бы научить работе с curses BSD-шным, чтобы оно не висло :)
у меня нет продакшен BSD, но попробую собрать, проверить..
Ага, спасибо. И неплохо было бы научить работе с curses BSD-шным,
чтобы оно не висло :)
А есть вариант проверить на freebsd? Я имею ввиду что собрать и
установить у меня получилось, именно проверить работоспособность. Это
патч к портам
| Sysop: | Angel Ripoll |
|---|---|
| Location: | Madrid, Spain |
| Users: | 16 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 126:30:51 |
| Calls: | 1,388 |
| Files: | 2,871 |
| D/L today: |
5 files (8K bytes) |
| Messages: | 72,194 |