Комментарии 8
> «и при вашем желании слушать дальше этот перевод.»
Да, спасибо, давайте дальше
Да, спасибо, давайте дальше
Мне кажется этой статье много неточностей например: iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT открывает один TCP порт, NFS же по умолчанию работает по UDP причем большому диапазону портов.
NFS <= 3 но не NFS 4. В 4-й один TCP порт является новшеством и фишкой позволяющей наконец настроить фаервол.
Насколько я помню в в NFS 3 тоже можно настроить через один TCP порт. Если честно точно не знаю, но мне казалось что в NFS 4 также по умолчанию UDP.
NFS в RHEL и CentOS, по умолчанию использует TCP в качестве транспорта.
www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-nfs.html#s1-nfs-how
www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-nfs.html#s1-nfs-how
Я понял чем мне не нравятся эти статьи.
Статья рассчитана на новичков, а по мне, так там ничего не объясняется. Описывается как сделать что-то, без объяснения зачем это делать, и почему именно так.
За перевод традиционное спасибо. Такие статьи полезны обществу. :)
Статья рассчитана на новичков, а по мне, так там ничего не объясняется. Описывается как сделать что-то, без объяснения зачем это делать, и почему именно так.
За перевод традиционное спасибо. Такие статьи полезны обществу. :)
Такие статьи тоже не бесполезны для общества *
У меня не меньше «претензий» к материалу. Т.е. мы либо учимся, взвешивая варианты, либо читаем такик tutorial'ы. Зачем оно лично мне надо? Комментарии. Ваш в том числе. Например, в прошлой статье этого цикла вы мне «подарили» аббревиатуру «NOC», и по этому тэгу я на одном только хабре нашел много интересного материала.
Критика тех или иных подходов в архитектуре сервера, основанная на вашей практики, порождает точки входа в google. По моему это уже ценно. Выше в комментариях вылезли вопросы о портах в различных версиях протокола NFS, хотя само использование этого протокола, как наиболее/наименее подходящего для работы никем еще не обсуждалось, а камни в прошлой статье уже кидались в нее.
Было бы интересно послушать альтернативные взгляды на архитектуру. Меня не покидает чувство, что автор текста, так же как и я, когда сидит на сервере, то протоколирует putty в лог-файл, исправляет ошибочные шаги, удаляет лишнее и получается вот такой вот пошаговый инструктаж. Честь ему за то и хвала, т.к. у меня не хватило сил довести свои протоколы настройки до цельной статьи.
Сами cyberciti.biz, авторы этого текста, позиционируют себя как большой FAQ. На него же похож howtoforge.com И у первых и у вторых я смотрю доп.материалы по возникающим вопросам и было бы здорово, если у меня получилось бы зацепить этим материалом темы для следующих переводов. Перевести многостраничные гайды по линуксу или фре — ну это вообще не формат сайта, хотя переводя вчитываешься гораздо глубже.
Я побоялся делать интро от себя, рассказывая, с какой проблемой столкнулся и для чего меня понесло в виртуализацию, которую в данном материале и виртуализацией назвать не выходит. Найду материал по своей тематике — сразу сюда притащу.
Если в общих чертах, то есть дефицит доступной информации, best practics от серьезных администраторов. Т.е. у меня есть задача — сайт с немаленькой аудиторией. Есть серверное хозяйство, которое нужно не только настроить раз в 5 лет и забыть, но и мониторить. Почему об этом никто из администраторов, настраивавших этот сервер прежде, не говорил владельцам ресурсов? Ну, потому что они — специалисты и они решили, что в нашем случае это не нужно. А когда настанет глубокая попа, когда кто-нибудь обнаружит, что есть проблемы в файловой системе, а SMART сыпет ошибки уже пол-года, тогда придет следующий администратор, перенесет все хозяйство на правильную архитектуру, поставит системы аналитики и мониторинга и до следующего «абзаца» все будут прибывать в неведении, что скрипт-кидиз давно и с любовью льют шелы через дырявый загрузчик картинок сайта в исполняемую директорию, а в движке сайта используется один популярный шелл в качестве менеджера файлов.
В прошлом материале завязался небольшой диалог с пользователем EugeneBond, который мне может оказаться более полезным, чем всякие туториалы. Ваш комментарий окажется более информационным чем вся статья. Т.е. переводится только ради разговора на эту тему. Если есть темы и нюансы, о которых есть что почитать на английском, но хотелось бы пообсуждать на русском языке — «бери, переводи, читай комменты». Мне ссылку можно бросить, если это по теме и будет интересно — почитаю, переведу, запощу, обсудим. Вот такой я хитрец. Ваши знания в обмен на мои переводы. ;)
Критика тех или иных подходов в архитектуре сервера, основанная на вашей практики, порождает точки входа в google. По моему это уже ценно. Выше в комментариях вылезли вопросы о портах в различных версиях протокола NFS, хотя само использование этого протокола, как наиболее/наименее подходящего для работы никем еще не обсуждалось, а камни в прошлой статье уже кидались в нее.
Было бы интересно послушать альтернативные взгляды на архитектуру. Меня не покидает чувство, что автор текста, так же как и я, когда сидит на сервере, то протоколирует putty в лог-файл, исправляет ошибочные шаги, удаляет лишнее и получается вот такой вот пошаговый инструктаж. Честь ему за то и хвала, т.к. у меня не хватило сил довести свои протоколы настройки до цельной статьи.
Сами cyberciti.biz, авторы этого текста, позиционируют себя как большой FAQ. На него же похож howtoforge.com И у первых и у вторых я смотрю доп.материалы по возникающим вопросам и было бы здорово, если у меня получилось бы зацепить этим материалом темы для следующих переводов. Перевести многостраничные гайды по линуксу или фре — ну это вообще не формат сайта, хотя переводя вчитываешься гораздо глубже.
Я побоялся делать интро от себя, рассказывая, с какой проблемой столкнулся и для чего меня понесло в виртуализацию, которую в данном материале и виртуализацией назвать не выходит. Найду материал по своей тематике — сразу сюда притащу.
Если в общих чертах, то есть дефицит доступной информации, best practics от серьезных администраторов. Т.е. у меня есть задача — сайт с немаленькой аудиторией. Есть серверное хозяйство, которое нужно не только настроить раз в 5 лет и забыть, но и мониторить. Почему об этом никто из администраторов, настраивавших этот сервер прежде, не говорил владельцам ресурсов? Ну, потому что они — специалисты и они решили, что в нашем случае это не нужно. А когда настанет глубокая попа, когда кто-нибудь обнаружит, что есть проблемы в файловой системе, а SMART сыпет ошибки уже пол-года, тогда придет следующий администратор, перенесет все хозяйство на правильную архитектуру, поставит системы аналитики и мониторинга и до следующего «абзаца» все будут прибывать в неведении, что скрипт-кидиз давно и с любовью льют шелы через дырявый загрузчик картинок сайта в исполняемую директорию, а в движке сайта используется один популярный шелл в качестве менеджера файлов.
В прошлом материале завязался небольшой диалог с пользователем EugeneBond, который мне может оказаться более полезным, чем всякие туториалы. Ваш комментарий окажется более информационным чем вся статья. Т.е. переводится только ради разговора на эту тему. Если есть темы и нюансы, о которых есть что почитать на английском, но хотелось бы пообсуждать на русском языке — «бери, переводи, читай комменты». Мне ссылку можно бросить, если это по теме и будет интересно — почитаю, переведу, запощу, обсудим. Вот такой я хитрец. Ваши знания в обмен на мои переводы. ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Повышаем безопасность стека web-приложений (виртуализация LAMP, шаг 1/6)