qmail
Доброй ночи Подскажите, кто-нибудь бодался с qmail? вопрос вот в чем.. поставил его из tar.gz откомпилял,прописал группы запускаю /var/qmail/rc & запускается демоны smtpd & pop3d вешаю в inetd как бы все запускается но проблема вот какая если я пробую смотреть почту из под маскарада то он почему то говорит что пароль не верен подскажите где грабли Евгений
Re:
Hello Jean, Monday, August 20, 2001, 8:03:25 AM, you wrote: > Добрый день . > Купил Debian 2.2 и нашёл доку в инете , все бы хорошо но вот не могу найти ни > какую инструкцию по руссификации и по использованию apt-get. > Не могли бы выслать чего нибудь на эту тему или указать ссылку. > Заранее благодарен. forwarding to russian support list -- Best regards, Aigarsmailto:[EMAIL PROTECTED]
TEItools
Hi All! А нет ли у кого deb пакета c TEItools. Очень мне нравилась эта вещь когда я под BlackCat раньше жил. (http://xtalk.opensource.ru:8100/SGML/TEItools/index-ru.html) -- Best regards, Gleb Galkin ... Ты, работа, нас не бойся, мы тебя не тронем.
Re: SSH2 & Restricted Shell ?
On Thu, Aug 23, 2001 at 08:36:26PM +0300, CuPoTKa wrote: > Konstantin V. Sorokin wrote: > > >On Thu, Aug 23, 2001 at 06:59:49PM +0300, CuPoTKa wrote: > > > >>Меня тоже давно гложет вопрос как сделать так чтоб лузеры не лазили > >>нигде, кроме своего хоума. Мне лично rbash вполне все это решает, > >>спасибо за совет. А может быть заодно поздскажите где именно прописать > >>вместо bash этот самый rbash особо "любимым" лузерам? > >> > > > >А я вот не понимаю зачем нужен rbash. И что плохого в том, что > >пользователи будут вылазить из своей домашней директории? > > > Ну как во первых чем мешьше лузер лазиет по системе тем меньше напортит, > а во вторых прочесть может что ему не пологается (за всем не уследишь). > А ограничить юзера домашней директорие решение мировое. > > Так вроде что не полагается и так не прочтет. Интересно, а куда это он может напортить? Я что-то не въезжаю. Примеры? -- WBR, Konstantin V. Sorokin :wq
Re[2]: HDD4Lin
Hello anti, Thursday, August 23, 2001, 8:51:13 PM, you wrote: armr> On Thu, Aug 23, 2001 at 04:13:39PM +0400, Andrey Nekrasov wrote: >> Hello dim, >> >> >> > ЮП> Да нет, сейчас реально выбирать надо из 2-х фирм IBM или Seagate (если >> > SCSI) >> > ЮП> если IDE то IBM или FUJITSU >> > >> > Да, забыл уточнить - ищу IDE'шник. >> >> Бери IBM IC35. 41Gb. Новыя модель конечно (это недостаток), но пока не >> сыпятся и >> вроде даже не греются. >> Можно также брать - Fujitsu/Seagate (Barracuda 3)/Maxtor/... >> >> >> Нельзя брать IBM DTLA 7200 rpm. armr> а можно узнать поконкретнее, почему? Да потому как дохнут они пачками и у нас и у буржуинов. -- Best regards, retmailto:[EMAIL PROTECTED]
Re: HDD4Lin
On Thu, Aug 23, 2001 at 08:01:18PM +0300, Alexei Khlebnikov wrote: > [EMAIL PROTECTED] wrote: > > > > Нельзя брать IBM DTLA 7200 rpm. > > > > а можно узнать поконкретнее, почему? > > Может попасться из плохой партии. У нас в конторе несколько таких веников > полетело, и > даже у меня дома один скопытился (хорошо что на гарантии был). К тому же, там > очень > слабые механические части, особенно там, где контакты питания соединяются с > платой (с > платой внизу винчестера). насчет "там, где контакты питания соединяются с ..." - это точно! пару раз сам наезжал на это, нечаянно задев рукой, корпус то постоянно открыт открыт :-( Однако, это уже не в тему debian-russian, sorry ... > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- AnTi
Re: HDD4Lin
[EMAIL PROTECTED] wrote: > > Нельзя брать IBM DTLA 7200 rpm. > > а можно узнать поконкретнее, почему? Может попасться из плохой партии. У нас в конторе несколько таких веников полетело, и даже у меня дома один скопытился (хорошо что на гарантии был). К тому же, там очень слабые механические части, особенно там, где контакты питания соединяются с платой (с платой внизу винчестера).
Re: SSH2 & Restricted Shell ?
Nick Potemkin wrote: On Thu, Aug 23, 2001 at 07:15:45PM +0300, CuPoTKa wrote: Может есть еще что-нибудь такое, что поможет шаловливому лузеру обойти restriction? $ man bash ... When a command that is found to be a shell script is exe╜ cuted (see COMMAND EXECUTION above), rbash turns off any restrictions in the shell spawned to execute the script. :) Мож я плохо по англицки но тут написано "когда команда которая является шелл спкиптом запускается..." С каких пор mc является shell scriptом? Хотя если лузер способен написать скриптину то он обойдет все restrictions. Есть еще идеи у народа как сделать, чтоб лузер не вылезал из своего home?
Re: SSH2 & Restricted Shell ?
CuPoTKa wrote: > Нужно, чтобы пользователи через SSH или SFTP не могли подняться выше > своего HOME. > Какие могут быть решения ? > В коммерческом SSHе если статически собирать демон, то можно в > настройках сервера указывать, что определенные усеры обделены... > И всё будет как надо (я так понял из документации) > > А что делать в моём случае ? проблема-то широкая имхо, многие > наверное сталкивались ? Может какой-нить рестрикнутый шелл этим > усерам нужен ? > > >>>Может "bash --restricted" подойдет? > >>> > >>Ага меня тоже гложет вопрост как бы сделать так, чтоб шаловливые юзеры > >>не лазиле по машине. rbash вроде для этих целей подходит. Прочел man > >>bash (только нужную часть конечно :) а то он ну чень длинный). > >>Может быть заодно подскажите где именно задать чтоб у юзера был не > >>просто bash а rbash? > >> > > > >Дык вроде очевидно: в /etc/passwd. > >Можно еще команду chsh запретить. > > > Вы уж извините за навязчивозть, но я так сказать еще учусь. Про > /etc/passwd понял. > А как запретить chsh и заодно mc, которая оказывается позволяет лузеру > путешествовать где хочет, несмотря на rbash. Например так: === addgroup Ly3ep chgrp Ly3ep `which chsh` `which mc` chmod g-rwx `which chsh` `which mc` adduser vasya Ly3ep adduser petya Ly3ep adduser existing_user_number_999 Ly3ep === > Может есть еще что-нибудь > такое, что поможет шаловливому лузеру обойти restriction? Конечно! Он может: 1) Запустить обычный bash или другой шелл. 2) Скачать сырцы bash, скомпилировать их (ох и трудно ему будет без значка '/' ;). 3) Скомпилировать bash на другой машине, слинковать статически, принести результат на эту машину, запустить. 4) Скомпилировать другой шелл или mc. 5) Написать и скомпилировать свою прогу, которая будет читать файлы там, где ему надо. 6) Да мало ли еще что.
Re: HDD4Lin
On Thu, Aug 23, 2001 at 04:13:39PM +0400, Andrey Nekrasov wrote: > Hello dim, > > > > ЮП> Да нет, сейчас реально выбирать надо из 2-х фирм IBM или Seagate (если > > SCSI) > > ЮП> если IDE то IBM или FUJITSU > > > > Да, забыл уточнить - ищу IDE'шник. > > Бери IBM IC35. 41Gb. Новыя модель конечно (это недостаток), но пока не > сыпятся и > вроде даже не греются. > Можно также брать - Fujitsu/Seagate (Barracuda 3)/Maxtor/... > > > Нельзя брать IBM DTLA 7200 rpm. а можно узнать поконкретнее, почему? -- AnTi
Re: SSH2 & Restricted Shell ?
On Thu, Aug 23, 2001 at 07:15:45PM +0300, CuPoTKa wrote: > Может есть еще что-нибудь > такое, что поможет шаловливому лузеру обойти restriction? $ man bash ... When a command that is found to be a shell script is exe╜ cuted (see COMMAND EXECUTION above), rbash turns off any restrictions in the shell spawned to execute the script. :) -- Nick Potemkin Eniro Rus-M http://www.eniro-m.ru ::: Yellow Pages Moscow http://www.yellowpages.ru phone: +7 (095) 799-55-55 fax: +7 (095) 799-55-09
Re: SSH2 & Restricted Shell ?
Alexei Khlebnikov wrote: CuPoTKa wrote: Нужно, чтобы пользователи через SSH или SFTP не могли подняться выше своего HOME. Какие могут быть решения ? В коммерческом SSHе если статически собирать демон, то можно в настройках сервера указывать, что определенные усеры обделены... И всё будет как надо (я так понял из документации) А что делать в моём случае ? проблема-то широкая имхо, многие наверное сталкивались ? Может какой-нить рестрикнутый шелл этим усерам нужен ? Может "bash --restricted" подойдет? Ага меня тоже гложет вопрост как бы сделать так, чтоб шаловливые юзеры не лазиле по машине. rbash вроде для этих целей подходит. Прочел man bash (только нужную часть конечно :) а то он ну чень длинный). Может быть заодно подскажите где именно задать чтоб у юзера был не просто bash а rbash? Дык вроде очевидно: в /etc/passwd. Можно еще команду chsh запретить. Вы уж извините за навязчивозть, но я так сказать еще учусь. Про /etc/passwd понял. А как запретить chsh и заодно mc, которая оказывается позволяет лузеру путешествовать где хочет, несмотря на rbash. Может есть еще что-нибудь такое, что поможет шаловливому лузеру обойти restriction?
Re: SSH2 & Restricted Shell ?
On Thu, Aug 23, 2001 at 06:59:49PM +0300, CuPoTKa wrote: > Меня тоже давно гложет вопрос как сделать так чтоб лузеры не лазили > нигде, кроме своего хоума. Мне лично rbash вполне все это решает, > спасибо за совет. А может быть заодно поздскажите где именно прописать > вместо bash этот самый rbash особо "любимым" лузерам? > А я вот не понимаю зачем нужен rbash. И что плохого в том, что пользователи будут вылазить из своей домашней директории? -- WBR, Konstantin V. Sorokin :wq
Re: SSH2 & Restricted Shell ?
Alexei Khlebnikov wrote: Dmitry Korotkov wrote: Hello debian-russian, Имею OpenSSH2. Нужно, чтобы пользователи через SSH или SFTP не могли подняться выше своего HOME. Какие могут быть решения ? В коммерческом SSHе если статически собирать демон, то можно в настройках сервера указывать, что определенные усеры обделены... И всё будет как надо (я так понял из документации) А что делать в моём случае ? проблема-то широкая имхо, многие наверное сталкивались ? Может какой-нить рестрикнутый шелл этим усерам нужен ? Может "bash --restricted" подойдет? Меня тоже давно гложет вопрос как сделать так чтоб лузеры не лазили нигде, кроме своего хоума. Мне лично rbash вполне все это решает, спасибо за совет. А может быть заодно поздскажите где именно прописать вместо bash этот самый rbash особо "любимым" лузерам?
Re: SSH2 & Restricted Shell ?
CuPoTKa wrote: > >> Нужно, чтобы пользователи через SSH или SFTP не могли подняться выше > >> своего HOME. > >> Какие могут быть решения ? > >> В коммерческом SSHе если статически собирать демон, то можно в > >> настройках сервера указывать, что определенные усеры обделены... > >> И всё будет как надо (я так понял из документации) > >> > >> А что делать в моём случае ? проблема-то широкая имхо, многие > >> наверное сталкивались ? Может какой-нить рестрикнутый шелл этим > >> усерам нужен ? > >> > > > >Может "bash --restricted" подойдет? > > > Ага меня тоже гложет вопрост как бы сделать так, чтоб шаловливые юзеры > не лазиле по машине. rbash вроде для этих целей подходит. Прочел man > bash (только нужную часть конечно :) а то он ну чень длинный). > Может быть заодно подскажите где именно задать чтоб у юзера был не > просто bash а rbash? Дык вроде очевидно: в /etc/passwd. Можно еще команду chsh запретить.
Re: 514 shell
On Thu, 23 Aug 2001, Alexei Khlebnikov wrote: > > Я лично всегда поступаю строго наоборот - отключаю НЕАНОНИМНЫЙ ftp > > для всех юзеров, имеющих настоящий shell. > > Зачем? Чтобы "все использовали правильный инструмент - rcp" ? Затем чтобы пароли не бегали где не надо и не залипали в кэшах всяких эксплойтеров. > Согласен, я сам так делал. Однако, такие задачи, как правило, целесообразно > пускать на > машинах с мощным процессором, а не слабым. И не через pipe все это > передавать, а, например, > монтировать удаленно файловую систему. Вот от nfs я практически отказался. rsh/ssh ее практически полностью заменяют. nfs я употребляю только для рутов бездисковых терминалов. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: 514 shell
Victor Wagner wrote: > On Thu, 23 Aug 2001, Alexei Khlebnikov wrote: > > Ну, сетка была не ахти, для любых соединений. Был коаксиал, разные части > > были куплены > > и монтированы разными людьми с руками разной кривизны. Скорость была > > 200-300 Кб/с по > > ssh. А без ssh было 200-900 Кб/с. Быстрее конечно, но не намного, да и > > замеры в той > > сетке хрен проведешь, особенно когда не знаешь, сколько еще человек > > совместно с тобой > > сеть используют. > > 900 vs 300 это ненамного? Да 900 - это пиковая скорость была, она почти никогда не достилгалась. Обычно 500-600 было. А подождать минуту (20 мегов на скорости 300 Кб/с) или 2-3 минуты (600-900 Кб/с) - не такая уж большая разница. > > > И все та-а-кие интерактивные прям зло берет. Один wget хоть на что-то > > > пригоден, но он к сожалению, только оттуда сюда умеет. Так что придется > > > тебе rsh otherhost wget yourhost делать. А вот ftp сервер его > > > действительно надо конфигурить и администрить, в отличие от in.rshd > > > > Ну почему. Можно взять netkit ftpd (пакет ftpd) и отключить anonymous ftp. > > И потом уже > > только имбицил может сделать что-то неправильно. > > Я лично всегда поступаю строго наоборот - отключаю НЕАНОНИМНЫЙ ftp > для всех юзеров, имеющих настоящий shell. Зачем? Чтобы "все использовали правильный инструмент - rcp" ? > > > Все это предполагает, что прежде чем файлы передаются с машины на машину > > > они > > > а) существуют на исходной машине именно как файлы, а не генерятся по ходу > > > дела > > > б) с ними там проделывают какие-то манипуляции. > > > > Ну, тут rsh конечно дает выигрыш, но он не такой уж и большой, потому как > > на медленных > > машинах редко большие винчестеры встретишь, поэтому качать, как правило, > > немного надо. > > Понимаешь ли, объем данных, которые могут быть сгенерены по ходу дела > программой может на порядки превосходить объем винчестера. Согласен, я сам так делал. Однако, такие задачи, как правило, целесообразно пускать на машинах с мощным процессором, а не слабым. И не через pipe все это передавать, а, например, монтировать удаленно файловую систему.
Re: 514 shell
On Thu, 23 Aug 2001, Alexei Khlebnikov wrote: > Ну, сетка была не ахти, для любых соединений. Был коаксиал, разные части были > куплены > и монтированы разными людьми с руками разной кривизны. Скорость была 200-300 > Кб/с по > ssh. А без ssh было 200-900 Кб/с. Быстрее конечно, но не намного, да и замеры > в той > сетке хрен проведешь, особенно когда не знаешь, сколько еще человек совместно > с тобой > сеть используют. 900 vs 300 это ненамного? > > В этом случае происходило exec rlogin. > > Ты имеешь ввиду, что "rsh не передавал пароль, он вызвал rlogin; rlogin > передавал > пароль" ? Да естественно. Потому что rsh в норме используется не для запуска интерактивной сессии, а для удаленного выполнения команд. В этом случае он паролей не передает. > > И все та-а-кие интерактивные прям зло берет. Один wget хоть на что-то > > пригоден, но он к сожалению, только оттуда сюда умеет. Так что придется > > тебе rsh otherhost wget yourhost делать. А вот ftp сервер его > > действительно надо конфигурить и администрить, в отличие от in.rshd > > Ну почему. Можно взять netkit ftpd (пакет ftpd) и отключить anonymous ftp. И > потом уже > только имбицил может сделать что-то неправильно. Я лично всегда поступаю строго наоборот - отключаю НЕАНОНИМНЫЙ ftp для всех юзеров, имеющих настоящий shell. > > > > > Х-ы. А если хочется одной командой все переписать - wget'ом можно. А если > > > не > > > хочется пароль в командной строке писать (в super trusted локалке?) - > > > можно на trusted локалка не означает что trusted все, кто тебе через плечо смотрят. > > Все это предполагает, что прежде чем файлы передаются с машины на машину > > они > > а) существуют на исходной машине именно как файлы, а не генерятся по ходу > > дела > > б) с ними там проделывают какие-то манипуляции. > > Ну, тут rsh конечно дает выигрыш, но он не такой уж и большой, потому как на > медленных > машинах редко большие винчестеры встретишь, поэтому качать, как правило, > немного надо. Понимаешь ли, объем данных, которые могут быть сгенерены по ходу дела программой может на порядки превосходить объем винчестера. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: SSH2 & Restricted Shell ?
Dmitry Korotkov wrote:
> Hello debian-russian,
>
> Имею OpenSSH2.
> Нужно, чтобы пользователи через SSH или SFTP не могли подняться выше
> своего HOME.
> Какие могут быть решения ?
> В коммерческом SSHе если статически собирать демон, то можно в
> настройках сервера указывать, что определенные усеры обделены...
> И всё будет как надо (я так понял из документации)
>
> А что делать в моём случае ? проблема-то широкая имхо, многие
> наверное сталкивались ? Может какой-нить рестрикнутый шелл этим
> усерам нужен ?
Может "bash --restricted" подойдет?
>
> --
> Best regards,
> Dmitry mailto:[EMAIL PROTECTED]
>
> N┘
> [EMAIL PROTECTED]
> И ┼[huФБjzН│х ·╥╙│К-√+-│в⌡┴╘Х╝"╤╛│╦чrз │{.nг+┴╥⌠╝▀⌡*Ю┐·ж°╤X╛╤f╛│ЙЕ┼кluФБjz+
The Bat настрой.
Re: translation of 'bug'
Alexey Vyskubov wrote: > > а кто-нибудь помнит/может рассказать тезисы, почему на debian.org слово > > bug переводится как "проблема", а не как-нибудь иначе? > > Просто любопытно -- а какие есть варианты? Ошибка -- не вариант. Жучок. (с) переводчик книги Страуструпа "Язык программирования С++" :-))
Re: 514 shell
Victor Wagner wrote: > > > > Я использовал ssh на 486/dx33 и не чувствовал торможения (и как клиент, > > > > и как > > > > сервер). > > > > > > А ты бэкапиться им пробовал? > > > > Ну, не бэкапиться, но качать туда-сюда несколько десятков мегов - да. (У > > машины > > был диск 260 Мб). > > Странно, я при перекачивании уже 3-4 мегов sсp на pentium 133 > успеваю начать материться что не rcp запустил. Даже на 10-мегабитнойэ > сетке. Ну, сетка была не ахти, для любых соединений. Был коаксиал, разные части были куплены и монтированы разными людьми с руками разной кривизны. Скорость была 200-300 Кб/с по ssh. А без ssh было 200-900 Кб/с. Быстрее конечно, но не намного, да и замеры в той сетке хрен проведешь, особенно когда не знаешь, сколько еще человек совместно с тобой сеть используют. > > Со мной происходила такая ситуация. "Хост на который идут" содержал пустой > > ~/.rhosts, соответственно он не доверял "хосту с которого идут". Я ввел > > команду: > > rsh -l cooluser host.kudaidut > > У меня спросили: > > cooluser password: > > Я написал пароль и оказался в шелле на "хосте на который идут". > > Что происходило в этом случае ? Что передавалось вместо пароля? > > В этом случае происходило exec rlogin. Ты имеешь ввиду, что "rsh не передавал пароль, он вызвал rlogin; rlogin передавал пароль" ? > > > Что касается использования ftp вместо rcp сие есть КРАЙНЕ неудобно. > > > > Прям уж "КРАЙНЕ". Нормально. И клиентов скока хочешь - хоть под консоль, > > хоть > > И все та-а-кие интерактивные прям зло берет. Один wget хоть на что-то > пригоден, но он к сожалению, только оттуда сюда умеет. Так что придется > тебе rsh otherhost wget yourhost делать. А вот ftp сервер его > действительно надо конфигурить и администрить, в отличие от in.rshd Ну почему. Можно взять netkit ftpd (пакет ftpd) и отключить anonymous ftp. И потом уже только имбицил может сделать что-то неправильно. > > Х-ы. А если хочется одной командой все переписать - wget'ом можно. А если не > > хочется пароль в командной строке писать (в super trusted локалке?) - можно > > на > > http-область архив положить и опять таки wget'ом. > > Все это предполагает, что прежде чем файлы передаются с машины на машину > они > а) существуют на исходной машине именно как файлы, а не генерятся по ходу > дела > б) с ними там проделывают какие-то манипуляции. Ну, тут rsh конечно дает выигрыш, но он не такой уж и большой, потому как на медленных машинах редко большие винчестеры встретишь, поэтому качать, как правило, немного надо. > rsh/rcp хороши тем, что позволяют рассматривать всю сетку как единую > рабочую среду. ssh/scp обладают тем же свойством, но имеют существенный > недостаток, например при запуске X-овых программ. > > Представим себе вот такую ситуацию > > Есть три машины - a, b и c > AB C > ++---+ ethernet > > Я сижу на машине A. Это X-терминал, поэтому сессия у меня на машине B. > Все кнопки, которые я нажимаю ВСЕ РАВНО передаются по сети по > некриптованному X-протоколу. > > Если я в открытьм на машине B xterm запускаю > rsh C программа > > то программа, запущеная на машине C непосредственно коннектится к > моему X-серверу A. > > Если я говорю > > ssh C программа > > то ssh пробрасывает ввод-вывод программы с C на B по криптованному > туннелю, а уж потом оно идет по тому же самому ethernet с B на A > по открытому протоколу. Спасибо, я не знал. > > Кстати, а rcp докачку поддерживает? > Нет. А что у тебя часто локалка обрывается? Нет. Я просто спросил. >
Re: translation of 'bug'
> а кто-нибудь помнит/может рассказать тезисы, почему на debian.org слово > bug переводится как "проблема", а не как-нибудь иначе? Просто любопытно -- а какие есть варианты? Ошибка -- не вариант. -- Алексей
translation of 'bug'
Привет, а кто-нибудь помнит/может рассказать тезисы, почему на debian.org слово bug переводится как "проблема", а не как-нибудь иначе? -- /\/\ike
Re: HDD4Lin
Hello dim, > ЮП> Да нет, сейчас реально выбирать надо из 2-х фирм IBM или Seagate (если > SCSI) > ЮП> если IDE то IBM или FUJITSU > > Да, забыл уточнить - ищу IDE'шник. Бери IBM IC35. 41Gb. Новыя модель конечно (это недостаток), но пока не сыпятся и вроде даже не греются. Можно также брать - Fujitsu/Seagate (Barracuda 3)/Maxtor/... Нельзя брать IBM DTLA 7200 rpm. -- bye. Andrey Nekrasov, SpyLOG.
Re: 514 shell
On Thu, 23 Aug 2001, Alexei Khlebnikov wrote: > > > Хм. Удобнее? 3 порта держать открытыми, за 3 прогами-серверами следить? > > > Да хоть двадцать. В локальной-то сети. > > 3 проги поддерживать вместо одной - это удобнЕЕ ? А чего их поддерживать? У них мейнтейнер есть. > > > Я использовал ssh на 486/dx33 и не чувствовал торможения (и как клиент, и > > > как > > > сервер). > > > > А ты бэкапиться им пробовал? > > Ну, не бэкапиться, но качать туда-сюда несколько десятков мегов - да. (У > машины > был диск 260 Мб). Странно, я при перекачивании уже 3-4 мегов sсp на pentium 133 успеваю начать материться что не rcp запустил. Даже на 10-мегабитнойэ сетке. > Со мной происходила такая ситуация. "Хост на который идут" содержал пустой > ~/.rhosts, соответственно он не доверял "хосту с которого идут". Я ввел > команду: > rsh -l cooluser host.kudaidut > У меня спросили: > cooluser password: > Я написал пароль и оказался в шелле на "хосте на который идут". > Что происходило в этом случае ? Что передавалось вместо пароля? В этом случае происходило exec rlogin. > > Что касается использования ftp вместо rcp сие есть КРАЙНЕ неудобно. > > Прям уж "КРАЙНЕ". Нормально. И клиентов скока хочешь - хоть под консоль, хоть > под И все та-а-кие интерактивные прям зло берет. Один wget хоть на что-то пригоден, но он к сожалению, только оттуда сюда умеет. Так что придется тебе rsh otherhost wget yourhost делать. А вот ftp сервер его действительно надо конфигурить и администрить, в отличие от in.rshd > Х-ы. А если хочется одной командой все переписать - wget'ом можно. А если не > хочется пароль в командной строке писать (в super trusted локалке?) - можно на > http-область архив положить и опять таки wget'ом. Все это предполагает, что прежде чем файлы передаются с машины на машину они а) существуют на исходной машине именно как файлы, а не генерятся по ходу дела б) с ними там проделывают какие-то манипуляции. rsh/rcp хороши тем, что позволяют рассматривать всю сетку как единую рабочую среду. ssh/scp обладают тем же свойством, но имеют существенный недостаток, например при запуске X-овых программ. Представим себе вот такую ситуацию Есть три машины - a, b и c AB C ++---+ ethernet Я сижу на машине A. Это X-терминал, поэтому сессия у меня на машине B. Все кнопки, которые я нажимаю ВСЕ РАВНО передаются по сети по некриптованному X-протоколу. Если я в открытьм на машине B xterm запускаю rsh C программа то программа, запущеная на машине C непосредственно коннектится к моему X-серверу A. Если я говорю ssh C программа то ssh пробрасывает ввод-вывод программы с C на B по криптованному туннелю, а уж потом оно идет по тому же самому ethernet с B на A по открытому протоколу. > Кстати, а rcp докачку поддерживает? Нет. А что у тебя часто локалка обрывается? Вообще я гораздо чаще делаю tar -cf - something |rsh otherhost tar -xf - чем rcp -r something otherhost: Вообще, надо избавляться от привычки смотреть на систему как на свалку файлов. Это в DOS с ее вырожденным алгоритмом scheduling так было. Unix это не свалка файлов, а клетка для процессов. Поэтому протоколы для удаленного выполнения комманд гораздо удобнее и естественные чем протоколы для передачи файлов.и -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: 514 shell
Victor Wagner wrote: > > > Есть ситуации, когда > > > rsh удобнее чем ssh (trusted локальная сеть, слабые процессоры). > > > > Хм. Удобнее? 3 порта держать открытыми, за 3 прогами-серверами следить? > Да хоть двадцать. В локальной-то сети. 3 проги поддерживать вместо одной - это удобнЕЕ ? > > Я использовал ssh на 486/dx33 и не чувствовал торможения (и как клиент, и > > как > > сервер). > > А ты бэкапиться им пробовал? Ну, не бэкапиться, но качать туда-сюда несколько десятков мегов - да. (У машины был диск 260 Мб). > > > Кроме того, заметим что rsh не передает по сети паролей НИ ПРИ КАКИХ > > > обстоятельствах. > > > > Не знал. А что же он передает? > > Только имя. rsh предполагает, что хост на который идут, доверяет хосту > с которого идут на предмет аутентикации юзверей. Со мной происходила такая ситуация. "Хост на который идут" содержал пустой ~/.rhosts, соответственно он не доверял "хосту с которого идут". Я ввел команду: rsh -l cooluser host.kudaidut У меня спросили: cooluser password: Я написал пароль и оказался в шелле на "хосте на который идут". Что происходило в этом случае ? Что передавалось вместо пароля? > > > Поэтому в случае если исключен DNS- и IP- spoofing, > > > а заснифливание передаваемых данных не волнует (например при бэкапе > > > больших объемов по локальной сети) rsh полезен. > > > > Внутренний голос подсказывает мне, что ftp с этим справится лучше (по > > крайней > > мере, в случае немногих больших файлов, а не многих маленьких). > > Бэкапом обычно называется полное копирование структуры файловой системы > на ленту. Соответственно, поток данных у тебя обычно один - файлы уже > собрала в кучку софтина, делающая бэкап - dump, tar. > А на другой стороне, это должно быть подано на вход программы, которая > пишет на ленту. > > Что касается использования ftp вместо rcp сие есть КРАЙНЕ неудобно. Прям уж "КРАЙНЕ". Нормально. И клиентов скока хочешь - хоть под консоль, хоть под Х-ы. А если хочется одной командой все переписать - wget'ом можно. А если не хочется пароль в командной строке писать (в super trusted локалке?) - можно на http-область архив положить и опять таки wget'ом. Кстати, а rcp докачку поддерживает?
Re: Exim
On Thu, Aug 23, 2001 at 02:52:48PM +0500, Alexei M. Victorovich wrote: > On Thu, Aug 23, 2001 at 03:02:49PM +0600, ÐлекÑей Ð. СпиÑÑн (Aleksey A. > Spitsin) wrote: > > Hello debian-russian, > > > > Хело ÐÐÐ. > > ÐÑо ÑазбиÑалÑÑ Ñ ÐµÐºÑимом в демÑÑне оÑкликниÑеÑÑ.. > > ÐнÑеÑеÑÑÐµÑ Ð² пеÑвÑÑ Ð¾ÑеÑÐµÐ´Ñ Ð½Ð°Ð¿Ð¸Ñание ÑилÑÑÑа Ð´Ð»Ñ ÑообÑений.. > > ÐÑло дело... > РпакеÑе exim-doc еÑÑÑ Ð¿Ð¾Ð´ÑÐ¾Ð±Ð½Ð°Ñ Ð¸Ð½ÑоÑмаÑÐ¸Ñ Ð¿Ð¾ наÑÑÑойке, в Ñом ÑиÑле и по > ÑилÑÑÑам, Ñ Ð¿ÑимеÑами. > ÐоÑиÑай ее и еÑли вопÑоÑÑ ÐµÑе оÑÑанÑÑÑÑ, пиÑи на мÑло. Чем ÑмогÑ... Sorry, по ÑилÑÑÑам можно поÑиÑаÑÑ Ñайл /usr/share/doc/exim/filter.txt.gz > > > > > -- > > Best regards, > > ÐлекÑей mailto:[EMAIL PROTECTED] > > > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: 514 shell
On Thu, 23 Aug 2001, Alexei Khlebnikov wrote: > > > Есть ситуации, когда > > rsh удобнее чем ssh (trusted локальная сеть, слабые процессоры). > > Хм. Удобнее? 3 порта держать открытыми, за 3 прогами-серверами следить? Да хоть двадцать. В локальной-то сети. > Я использовал ssh на 486/dx33 и не чувствовал торможения (и как клиент, и как > сервер). А ты бэкапиться им пробовал? > > Кроме того, заметим что rsh не передает по сети паролей НИ ПРИ КАКИХ > > обстоятельствах. > > Не знал. А что же он передает? Только имя. rsh предполагает, что хост на который идут, доверяет хосту с которого идут на предмет аутентикации юзверей. > > Поэтому в случае если исключен DNS- и IP- spoofing, > > а заснифливание передаваемых данных не волнует (например при бэкапе > > больших объемов по локальной сети) rsh полезен. > > Внутренний голос подсказывает мне, что ftp с этим справится лучше (по крайней > мере, в случае немногих больших файлов, а не многих маленьких). Бэкапом обычно называется полное копирование структуры файловой системы на ленту. Соответственно, поток данных у тебя обычно один - файлы уже собрала в кучку софтина, делающая бэкап - dump, tar. А на другой стороне, это должно быть подано на вход программы, которая пишет на ленту. Что касается использования ftp вместо rcp сие есть КРАЙНЕ неудобно. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: Exim
On Thu, Aug 23, 2001 at 03:02:49PM +0600, ÐлекÑей Ð. СпиÑÑн (Aleksey A. Spitsin) wrote: > Hello debian-russian, > > Хело ÐÐÐ. > ÐÑо ÑазбиÑалÑÑ Ñ ÐµÐºÑимом в демÑÑне оÑкликниÑеÑÑ.. > ÐнÑеÑеÑÑÐµÑ Ð² пеÑвÑÑ Ð¾ÑеÑÐµÐ´Ñ Ð½Ð°Ð¿Ð¸Ñание ÑилÑÑÑа Ð´Ð»Ñ ÑообÑений.. ÐÑло дело... РпакеÑе exim-doc еÑÑÑ Ð¿Ð¾Ð´ÑÐ¾Ð±Ð½Ð°Ñ Ð¸Ð½ÑоÑмаÑÐ¸Ñ Ð¿Ð¾ наÑÑÑойке, в Ñом ÑиÑле и по ÑилÑÑÑам, Ñ Ð¿ÑимеÑами. ÐоÑиÑай ее и еÑли вопÑоÑÑ ÐµÑе оÑÑанÑÑÑÑ, пиÑи на мÑло. Чем ÑмогÑ... > > -- > Best regards, > ÐлекÑей mailto:[EMAIL PROTECTED] > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Exim
Hello debian-russian, Хело ÐÐÐ. ÐÑо ÑазбиÑалÑÑ Ñ ÐµÐºÑимом в демÑÑне оÑкликниÑеÑÑ.. ÐнÑеÑеÑÑÐµÑ Ð² пеÑвÑÑ Ð¾ÑеÑÐµÐ´Ñ Ð½Ð°Ð¿Ð¸Ñание ÑилÑÑÑа Ð´Ð»Ñ ÑообÑений.. -- Best regards, ÐлекÑей mailto:[EMAIL PROTECTED]
Re: 514 shell
Victor Wagner wrote: > > Мой тебе совет: не используй rsh. Лучше уж ssh. > > Мой совет - давая такие советы, аргументируй. Ok. > Есть ситуации, когда > rsh удобнее чем ssh (trusted локальная сеть, слабые процессоры). Хм. Удобнее? 3 порта держать открытыми, за 3 прогами-серверами следить? Я использовал ssh на 486/dx33 и не чувствовал торможения (и как клиент, и как сервер). > Кроме того, заметим что rsh не передает по сети паролей НИ ПРИ КАКИХ > обстоятельствах. Не знал. А что же он передает? > Поэтому в случае если исключен DNS- и IP- spoofing, > а заснифливание передаваемых данных не волнует (например при бэкапе > больших объемов по локальной сети) rsh полезен. Внутренний голос подсказывает мне, что ftp с этим справится лучше (по крайней мере, в случае немногих больших файлов, а не многих маленьких).
Re: 514 shell
On Thu, 23 Aug 2001, Alexei Khlebnikov wrote: > > > > очень содержательно... :( > > Так можно ведь еще сам файл почитать. Там рядом rlogin и другая фигня. > А еще можно /etc/inetd.conf почитать. Там тоже что-то про это написано. > Короче, это remote shell (rsh). > Deb-пакеты: rsh-client, rsh-server. > > Мой тебе совет: не используй rsh. Лучше уж ssh. Мой совет - давая такие советы, аргументируй. Есть ситуации, когда rsh удобнее чем ssh (trusted локальная сеть, слабые процессоры). Кроме того, заметим что rsh не передает по сети паролей НИ ПРИ КАКИХ обстоятельствах. Поэтому в случае если исключен DNS- и IP- spoofing, а заснифливание передаваемых данных не волнует (например при бэкапе больших объемов по локальной сети) rsh полезен. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: 514 shell
On Thu, 23 Aug 2001, Dmitry Glushenok wrote: > From: Dmitry Glushenok <[EMAIL PROTECTED]> > Subject: 514 shell > X-Mailer: The Bat! (v1.51) UNREG / CD5BF9353B3B7091 > > Hello debian-russian, > > сорри, оффтопик наверное, но, > нигде не могу найти описалово этой штуки на 514 порту.. > ткните носом! rfc какой-нить.. > и вообще, что за служба на этот порт вешается? apt-get install rsh-server (и затыкать, затыкать, затыкать и файрволлом, и tcpwrappers, чтобы кого не надо не пускал) -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: 514 shell
Dmitry Glushenok wrote: > просто интересным показалось, всмысле для чего-то он > ведь сделан, вот и решил покопаться :) Он был сделан для замены телнета, когда еще не придумали ssh. > еще у него какая-то странная процедура аутентификации: > телнетом лезешь, а там тишина.. > всмысле коннектится, а он молчит как партизан.. Аутентификация происходит через порт 513 (rlogin). И вроде как даже не plaintext'ом. Правда, и шифрования нету. А можно вообще без пароля заходить с определенных машин/юзеров (man rhosts). В ssh тоже все это можно, ты наверное знаешь. > так, к слову, что значит % backup authentification > при попытке логина по телнету (23 порт, не 514 ;)? Не знаю.
Re[2]: 514 shell
Hello Alexei, ssh и пользую :) просто интересным показалось, всмысле для чего-то он ведь сделан, вот и решил покопаться :) еще у него какая-то странная процедура аутентификации: телнетом лезешь, а там тишина.. всмысле коннектится, а он молчит как партизан.. так, к слову, что значит % backup authentification при попытке логина по телнету (23 порт, не 514 ;)? Thursday, August 23, 2001, 12:09:44 PM, you wrote: AK> Dmitry Glushenok wrote: >> Hello Alexei, >> >> --- >> shell 514/tcp cmd # no passwords used >> --- >> >> очень содержательно... :( AK> Так можно ведь еще сам файл почитать. Там рядом rlogin и другая фигня. AK> А еще можно /etc/inetd.conf почитать. Там тоже что-то про это написано. AK> Короче, это remote shell (rsh). AK> Deb-пакеты: rsh-client, rsh-server. AK> Мой тебе совет: не используй rsh. Лучше уж ssh. -- Regards, Dmitry
Re: 514 shell
Dmitry Glushenok wrote: > Hello Alexei, > > --- > shell 514/tcp cmd # no passwords used > --- > > очень содержательно... :( Так можно ведь еще сам файл почитать. Там рядом rlogin и другая фигня. А еще можно /etc/inetd.conf почитать. Там тоже что-то про это написано. Короче, это remote shell (rsh). Deb-пакеты: rsh-client, rsh-server. Мой тебе совет: не используй rsh. Лучше уж ssh.
Re[2]: 514 shell
Hello Alexei, --- shell 514/tcp cmd # no passwords used --- очень содержательно... :( Thursday, August 23, 2001, 11:54:53 AM, you wrote: AK> Dmitry Glushenok wrote: >> нигде не могу найти описалово этой штуки на 514 порту.. >> и вообще, что за служба на этот порт вешается? AK> cat /etc/services | grep 514 -- Regards, Dmitry
Re: 514 shell
Dmitry Glushenok wrote: > нигде не могу найти описалово этой штуки на 514 порту.. > и вообще, что за служба на этот порт вешается? cat /etc/services | grep 514
Re: OFF: Теорема Ферм а ( Re: mpg123)
> Если бы у меня было это доказательство, я бы тебе рассказал, какие из > него > следствия. По-моему, если у нас есть некоторое > множество задач, которые мы не умеем решать простыми способами, и вдруг > одну из задач этого множества - научились, есть немаленький шанс, что > следствием из этого решения будет несколько десятков решений для других > задач из оного множества. Например, следствием доказательства теоремы > Ферма теми средствами, о которых знал сам Ферма, может внезапно > оказаться > эффективный алгоритм факторизации больших чисел. Дело-то в том, что о *методах* Ферма мы знаем все. Шанс, что он использовал что-то принципиально новое в единственном незаписанном доказательстве -- ноль :) -- Алексей
514 shell
Hello debian-russian, сорри, оффтопик наверное, но, нигде не могу найти описалово этой штуки на 514 порту.. ткните носом! rfc какой-нить.. и вообще, что за служба на этот порт вешается? -- Regards, Dmitry
Re: OFF: Теорема Ферма ( Re: mpg123)
On Wed, 22 Aug 2001, Alexey Vyskubov wrote: > From: Alexey Vyskubov <[EMAIL PROTECTED]> > Subject: Re: OFF: Теорема Ферма ( Re: mpg123) > > > Вот будет смешно, если еще лет через двести развития математики, > > раскопают-таки то доказательство, которое имел в виду Ферма - > > "поистине удивительное", понятное студенту-первокурснику, страницы на > > 3-4. > > Ведь из него же следствий тогда будет... > > Ну? Каких? ;) Если бы у меня было это доказательство, я бы тебе рассказал, какие из него следствия. По-моему, если у нас есть некоторое множество задач, которые мы не умеем решать простыми способами, и вдруг одну из задач этого множества - научились, есть немаленький шанс, что следствием из этого решения будет несколько десятков решений для других задач из оного множества. Например, следствием доказательства теоремы Ферма теми средствами, о которых знал сам Ферма, может внезапно оказаться эффективный алгоритм факторизации больших чисел. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
