>> Ок, но работает только для самописного клиента к чат-серверу.
> о котором я изначально и говорил все сообщения. мне кажется, тут есть
> недопонимание: этот самый «самописный клиент» — он является частью софта,
> который запускается на сервере после ssh-аутентификации. естественно, писать надо будет.
> так в любом же случае писать надо будет — кое-кто вон
> цельный ssh-сервер даже отгрохал там, где оно не надо.Просто из-за моей лени перечитать данную ветку комментариев, вместе с прочтением других веток комментариев, в моей голове сформировалась небольшая каша. Приношу извинения.
>> Одно дело какие-то символы "<32 || >127" (зачастую вредность которых выше пользы),
>> и совсем другое дело выколотые слова (состоящие из 4 lower latin
>> characters) из-за кривоты реализации.
> не вижу разницы. если кому-то жизнь не мила без любимого ника «root»,
> пусть примет таблетку от мегаломании.
Разница в том, как это выглядит перед пользователями, если делать настолько же удобно для тупого пользователя, как начали делать в subj-вом проекте. Там нет необходимости заходить сначала на guest-а, чтобы получить ник, а только потом логиниться с данным ником. Можно сразу заходить с новым ником. Предлагаете в motd высветить запрет использования root или как? Или это принципиальный запрет заходить сначала из под guest-а, а только потом под своим ником?
>>> нельзя «root». нельзя — и всё. eat it or GTFO.
>> Это одна из мелочей, с которой нужно смириться. Другая из мелочей, что
>> будет использовано намного больше ОЗУ.
> «намного больше» — по сравнению с чем?
В сравнении с хорошо написанным сервером, который всех обрабатывает одним процессом (но не потоком).
> я повторно скажу, что большинство страниц будут shared.
1. Страница - это обычно от 4КБ. Это конечно мелочь, но изменяем один байт и все 4КБ сжирают дополнительную страницу.
2. Если имеется процесс A, который форкается на A и B (и на этом конец), то да. Но если есть процесс A, который форкается на A и B, а потом в каждом делается exec (который перезатрёт всё в его памяти нафиг), то тогда уже нет. С другой стороны память можно дедуплицировать назад с помощью KSM. Хотя это не очень удобно, не очень быстро и слегка не очень безопасно (за счёт потенциальной возможности создания условий для дополнительных timing attack), но со всем можно смириться, конечно.
3. Возможно у каждого процесса будет полностью свой (без всяких shared) stack. Нужно проверить, таких тонкостей лично я не помню.
4. Это ещё одна мелочь, но всё-таки проблема не только в fork(), но и в том, что будет больше разных процессов. Каждый раз будет иметь свои какие-то прилинкованные библиотеки, "обёртки" (для обработки аргументов, конфигов и т.п.), реализации интерфейсов для взаимодействия между процессами и др.
>> Третья из мелочей — замусоривание /etc/{passwd,shadow,group,gshadow}
> кто мешает посадить это в отдельный контейнер? кстати, и безопасней будет. и
> даже рута можно позволить регистрировать. и безопасно, и мегаломаньяки могут ЧСВ
> потешить.
Да, я это предполагал такое решение в другом комментарии выше. Но тогда начинается новая волна проблем:
- Новая весьма немалая зависимость (как и в user-space, так и в kernel-space).
- Портируемость улетучивается нафиг (что следует из предыдущего пункта, но требует отдельного внимания).
- Как быть с сетью между хостом и контейнерами? Наиболее разумное решение, это вырубить unshare(CLONE_NEWNET), но не уверен, что это позволяется в docker/lxc.
- Потребность в OverlayFS для удобного обновления окружения (с AUFS есть отдельные проблемы, которые можно обсудить, если интересно). Что создаёт зависимость на новые ядра и создаёт мусор в /proc/mounts.
- Как быть, если потенциальным хостом является контейнер (предоставленный хостером на 1$ в месяц), и в нём вырублены capabilities, необходимые для создания дочерних контейнеров?
- ... Дальше думать лень, но мне кажется, что это далеко не конец.
>> и исчерпание UID-ов и GID-ов (что можно обойти через сомнительные по
>> безопасности костыли).
> десятки тысяч пользователей? (впрочем, насколько я помню, uid-ы таки 32-битные, так что…)
> без очистки дохлых хотя бы по дате последнего логина? ну ок.
> на таком беспризорном сервере это будет меньшая из проблем.
Да, только что перепроверил, вы правы. Около-16-битное ограничение было лишь со стороны /etc/login.defs.
>> Ну, естественно модульное решение предпочтительнее. Но его кто-то уже сделал?
> а никому не надо. сабжевое — тоже.
Так пусть это решит свободное сообщество. Другими словами, время покажет. Хотя там уже почти 1200 star-ов на github-е, что очень много для столь молодого проекта (проекту лишь почти месяц).
>>>>> но да, конечно, это всё нестильно. фу делать модульные решения из простых
>>>>> частей, фу! то ли дело — сразу свой ssh-сервер забабахать!
>>>> Лучше готового решения пока никто не написал.
>>> потому что никому нафиг не нужно. ну, из тех, кто может сделать
>>> нормальное решение. потому что если тем, кто может сделать нормальное решение,
>>> заявят, что «на работе нельзя ставить софт, но можно ssh» —
>>> эти люди покрутят пальцем у виска.
>> Не надо мешать в одну кучу пользователей и администраторов сервиса.
> и где я смешивал?
Тем, кому запрещают ставить другой софт -- это пользователи. А те, кто делает решение -- это администраторы.
>>> однако же вышенаписаное — ни разу не причина приветствовать решение, сдизайненое
>>> обезьяной-наркоманом.
>> Причина приветствовать -- грубо говоря, лучшее решение из существующих для определённой
>> ниши проблем. Меньшее из зол, так сказать.
> нет. это и ни то, и ни другое, это куча говна. куча
> говна — вообще никакое не решение.
То есть с вашей точки зрения лучше никакое "решение", чем такое. Я правильно понял?
>>>>> да ещё и на go.
>>>> Ну, это всяко лучше, чем на Python или Ruby. :)
>>> одна фигня. но руби хотя бы забавный.
>> Совсем не одна фигня. Golang хотя бы компилируемый.
> и какая разница? шифрование везде делается библиотеками в машинном коде, а всё
> остальное совершенно некритично.
Почему некритично? Шифрование бывает легковесным. Например, есть всем известный hpn-ssh. IIRC, я утилизировал Gbps, используя scp на i7 (на клиентской стороне) и ещё много ресурсов CPU осталось свободными. Если нужно, могу перепроверить. А пока давайте поделим на 1000, чтобы дойти до уровня сравнительно высоконагруженного чат-сервера. Хотите сказать, что RPi в 1000 слабее i7 (в рамках данной задачи)?
