>> Если вы развязываете ssh-сервер
>> и irc(/whatever else)-сервер друг от друга, то тогда авторизация по ssh
>> -- это одно, а авторизация на чат-сервере -- это уже другое.
>> Как объединить эти вещи?
> у никсов есть такое забавное апи, при помощи которого можно узнать, под
> каким же юзером мы запущены. самоочевидно, что для нашего случая это
> будет тот самый юзер, под которым мы залогинились. вот эту информацию
> клиент и передаёт серверу. поскольку сервер снаружи недоступен, а юзер ничего,
> окромя клиента, запустить не может, то есть смысл поверить клиенту, если
> он говорит, что это vasya.Ок, но работает только для самописного клиента к чат-серверу.
>>>> Как вы
>>>> предлагаете разрешить использование логина "root" в данном чате?
>>> зачем?
>> Затем, что запрещать использование логина "root" в чате из-за внутренних особенностей системы
>> -- это как-то криво. Я знаю пользователей в IRC-сетях, которые используют
>> данный ник.
> а нулевые символы в нике можно? как это «нельзя»? КРИВИЗНА!!!1111
Одно дело какие-то символы "<32 || >127" (зачастую вредность которых выше пользы), и совсем другое дело выколотые слова (состоящие из 4 lower latin characters) из-за кривоты реализации.
> нельзя «root». нельзя — и всё. eat it or GTFO.
Это одна из мелочей, с которой нужно смириться. Другая из мелочей, что будет использовано намного больше ОЗУ. Третья из мелочей -- замусоривание /etc/{passwd,shadow,group,gshadow} и исчерпание UID-ов и GID-ов (что можно обойти через сомнительные по безопасности костыли). И т.п.
> я сильно
> сомневаюсь, что это именно тот ужасный недостаток, из-за которого надо городить
> свой монолитный ssh-сервер вместо модульной системы.
Ну, естественно модульное решение предпочтительнее. Но его кто-то уже сделал?
>>> но да, конечно, это всё нестильно. фу делать модульные решения из простых
>>> частей, фу! то ли дело — сразу свой ssh-сервер забабахать!
>> Лучше готового решения пока никто не написал.
> потому что никому нафиг не нужно. ну, из тех, кто может сделать
> нормальное решение. потому что если тем, кто может сделать нормальное решение,
> заявят, что «на работе нельзя ставить софт, но можно ssh» —
> эти люди покрутят пальцем у виска.
Не надо мешать в одну кучу пользователей и администраторов сервиса.
> однако же вышенаписаное — ни разу не причина приветствовать решение, сдизайненое
> обезьяной-наркоманом.
Причина приветствовать -- грубо говоря, лучшее решение из существующих для определённой ниши проблем. Меньшее из зол, так сказать.
>>> да ещё и на go.
>> Ну, это всяко лучше, чем на Python или Ruby. :)
> одна фигня. но руби хотя бы забавный.
Совсем не одна фигня. Golang хотя бы компилируемый.
