Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 95
При добавлении пользователя в sudo, зачем редактировать sudoers? Можно же положить файлик в sudoers.d. Лучше так делать, чтобы потом свои конфиги не мержить при апгрейде.
Спасибо за ценный совет, исправил
А можно просто пользователя в группу sudo добавить.
Если несколько пользователей — то да, но в данном примере пользователь 1.
А в чем проблема добавить пользователя в специально созданную для таких целей группу?
Проблем нет, будет больше 1 пользователя с такими потребностями — создадим
Ее не надо создавать; она уже создана. И предназначена как раз для того, чтобы не делать user ALL=(ALL) ALL
Да и, раз уж на то пошлО, согласен с Demosfen-ом из комментария ниже — смысла в отдельном юзере, который администрирует личную VPS через постоянный sudo, лично я так и не понял.
Да и, раз уж на то пошлО, согласен с Demosfen-ом из комментария ниже — смысла в отдельном юзере, который администрирует личную VPS через постоянный sudo, лично я так и не понял.
Поправте если я не прав, я так понимаю что замена root на другого пользователя учетную запись нужна только для того, чтобы отключить возможность удаленного логина на систему под root и бандитам, теперь нужно подбирать не только пароль, но и неизвестное имя?
Авторизация по ключу и пусть подбирают до опупения.
PermitRootLogin without-password и fail2ban вынудят наших бандитов искать более другую систему.
Вообще статья в целом довольно неровная. Видно что автор старался, перелопатил некоторое количество документации, но при этом все еще допускает серьезные ошибки — не понимает назначения sudo; зачем-то ставит 64-битную систему на мизерное количество памяти; героически пишет свои скрипты для работы с iptables вместо того, чтобы использовать штатные средства…
Вообще статья в целом довольно неровная. Видно что автор старался, перелопатил некоторое количество документации, но при этом все еще допускает серьезные ошибки — не понимает назначения sudo; зачем-то ставит 64-битную систему на мизерное количество памяти; героически пишет свои скрипты для работы с iptables вместо того, чтобы использовать штатные средства…
Думаю, что для тех, кто попадёт на этот пост из гугла/яндекса по сабжу, пост будет полезен. Возможно даже очень.
Но вот для хабровчан… не уверен.
Но вот для хабровчан… не уверен.
Ну почему, не все же имеют опыт развёртывания МЗЫ по одному SSH
. У меня, правда, на другом бесплатном хостинге тоже дали доступ по SSH без SFTP, и на этом дело встало. Тут какие-то тонкие настройки имеются, добавят знаний, хотя SFTP, наверное, у автора есть, поэтому нет обсуждения того, как закачивать файлы только по SSH.
. У меня, правда, на другом бесплатном хостинге тоже дали доступ по SSH без SFTP, и на этом дело встало. Тут какие-то тонкие настройки имеются, добавят знаний, хотя SFTP, наверное, у автора есть, поэтому нет обсуждения того, как закачивать файлы только по SSH.
Горе тому хабравчанину, который не умеет пользоваться терминалом.
Как это ни странно, но в IT работают (и хабру читают) не только тех. специалисты, а практика показывает, что прочим ролям нет надобности лезть в терминал.
Вместе с тем, может появиться желание таки попробовать. Эта статья будет отличным подспорьем.
Да и кто из нас не был новичком? Невозможно ж сразу всё знать (:
Вместе с тем, может появиться желание таки попробовать. Эта статья будет отличным подспорьем.
Да и кто из нас не был новичком? Невозможно ж сразу всё знать (:
Типа SCP там, все дела?
Пишем сложный пароль(который вы не забудете!)и заполняем данные которые считаем нужными, или просто нажимаем enter.
Почти ко всем серверам не сохраняю и специально не записываю юзер пароли.
Перейти к юзеру из рута всегда можно без пароля, ftp/ssh клиенты поддерживают авторизацию по ключам…
В статье рекомендуется не сидеть под root-ом, для этого и был создан user.
На рабочей станции понятно. Но на сервере то на фига? В статье — создаем юзера и дальше все команды погнали через sudo. А смысл? Все равно на сервер нужно ходить только для его обслуживания, т.е. править конфиги, рестартить службы, обновляться и т.п.
Сами создаем себе препятствие и в каждой команде его преодолеваем.
Сами создаем себе препятствие и в каждой команде его преодолеваем.
Лишнее препятствие препятствует и криворукой невнимательности.
Так же неопытный пользователь всегда понимает что используется привилегии супер пользователя и что последствия могут быть серьезными.
P.S. Однажды перепутал консоли рабочей станции и сервера, и спасло лишь то что пароли от user были разные.
Так же неопытный пользователь всегда понимает что используется привилегии супер пользователя и что последствия могут быть серьезными.
P.S. Однажды перепутал консоли рабочей станции и сервера, и спасло лишь то что пароли от user были разные.
А что обычному юзеру делать на сервере? И что админу делать на сервере с правами обычного юзера — все равно ничего сделать не сможетю
Если это разработчик, которому нужен ssh, то даем ему обычный аккаунт без всякого sudo.
Во всех доках и так уже приучили к sudo, что это одна петрушка с работой под рутом. Был случай — начинающий горе-админ не задумываясь набрал в корне chown -R user:user . — весело было :)
Так что толку особо нет от этого. С файлами проектов работаем под юзером, админские задачи решаем под рутом. Пару раз ошибемся конколью и начнем следить что в ней написано — $ или # :)
Если это разработчик, которому нужен ssh, то даем ему обычный аккаунт без всякого sudo.
Во всех доках и так уже приучили к sudo, что это одна петрушка с работой под рутом. Был случай — начинающий горе-админ не задумываясь набрал в корне chown -R user:user . — весело было :)
Так что толку особо нет от этого. С файлами проектов работаем под юзером, админские задачи решаем под рутом. Пару раз ошибемся конколью и начнем следить что в ней написано — $ или # :)
Для себя решил проблему с определением консолей так:
на локальной машине промт цветной (force_color_prompt=yes в .bashrc для ubuntu), а на всех серверах монохромный.
Теперь перепутать невозможно.
на локальной машине промт цветной (force_color_prompt=yes в .bashrc для ubuntu), а на всех серверах монохромный.
Теперь перепутать невозможно.
P.S. Однажды перепутал консоли рабочей станции и сервера, и спасло лишь то что пароли от user были разные.
Раскрашенное приветствие в .bashrc спасает. Тоже после случайного ребута сервера пришел к такому.
ещё больше спасает отображение имени сервера в приветствии.
Это тоже есть.
Цвета воспринимаются объективно лучше, чем какой-то там текст.
дык я и не отрицал этого. имелось в виду, цвет+текст: img59.imageshack.us/img59/8127/7qc1.png
При этом доступ к нестандартному порту открыть только с определенных адресов, либо vpn.
Иначе безопасность в этом случае будет определяться рабочей станцией админа. Словили трояна, который стащит закрытый ключ и кейлоггером сцапает пароль к нему и досвидульки сервер.
Иначе безопасность в этом случае будет определяться рабочей станцией админа. Словили трояна, который стащит закрытый ключ и кейлоггером сцапает пароль к нему и досвидульки сервер.
То есть поднять на сервере vpn сервер, сменить порт ssh сервера и разрешить только локальный доступ по закрытым ключам без пароля?
Это уже для тру продакшн серверов, а против китайцев — паранойя.
Это уже для тру продакшн серверов, а против китайцев — паранойя.
Если подняли vpn, то не нужен нестандартный порт достаточно перевесить ssh на 127.0.0.1 или локальный адрес из левой сети vpn.
Собственно владельцы таких серверов, которые думают, что у них не тру-продакшен сервера, рано или поздно становятся либо частью ботнета, либо спам-шлюзом :( Либо становятся промежуточным хопом для взлома серьезных серверов — потом придется долго дядям в масках рассказывать, что это не вы ломали их сервер :)
Вообще vpn это только один вариантов. В принципе достаточно ограничить доступ только с ip своей рабочей машины. Либо port-knocking сделать.
В любом случае, при большом желании, в случае смены ip или на случай если забудете последовательность портов, всегда сможете получить доступ к локальной консоли сервера удаленно. Прошли уже времена когда надо было в серверную с клавой или монитором бегать в таких случаях. Сейчас или через гипервизор можно получить консоль, либо в случае железного сервака — через bmc/ilo и т.п.
Собственно владельцы таких серверов, которые думают, что у них не тру-продакшен сервера, рано или поздно становятся либо частью ботнета, либо спам-шлюзом :( Либо становятся промежуточным хопом для взлома серьезных серверов — потом придется долго дядям в масках рассказывать, что это не вы ломали их сервер :)
Вообще vpn это только один вариантов. В принципе достаточно ограничить доступ только с ip своей рабочей машины. Либо port-knocking сделать.
В любом случае, при большом желании, в случае смены ip или на случай если забудете последовательность портов, всегда сможете получить доступ к локальной консоли сервера удаленно. Прошли уже времена когда надо было в серверную с клавой или монитором бегать в таких случаях. Сейчас или через гипервизор можно получить консоль, либо в случае железного сервака — через bmc/ilo и т.п.
а пароль для sudo? Или NOPASSWD в sudoers?
используется пароль user-а для sudo по дефолту
Получается если украдут пароль у пользователя, то сразу получат рута. У нас на сервере так и было ) Больше никаких sudo.
Точно так же можно украсть пароль от root-а.
И не надо давать всем пользователям sudo, а только тем кому это явно требуется, например администраторам.
И не надо давать всем пользователям sudo, а только тем кому это явно требуется, например администраторам.
Ну пароль который надо каждый раз вводить в терминале, сложнее украсть чем сохраненный во всяких ftp/коммандерах. А вот пароль юзера который ходить по фтп угоняеться на раз (достаточно иметь заразного соседа в подсети). sftp кое как решает, но риск всеравно слишком большой.
Мое мнение, никаких sudo, никаких паролей по ssh, и su только у админа/хозяина.
Мое мнение, никаких sudo, никаких паролей по ssh, и su только у админа/хозяина.
А root-а держать без пароля (как на убунте по дефолту). И авторизоваться, если нужно, входя отдельной сессией с авторизацией по ключу.
Про оптимальную настройку WSGI под Python для такой скромной конфигурации тоже было бы интересно почитать.
За эти деньги можно у digitalocean взять впс на KVM с 512 ОЗУ и дисковой SSD. А тут еще 2а дня проблемы с сетью у Вас были :-)
NY? Некоторым могут быть пинги критичны.
У меня на hostink.ru тоже виртуальный сервер для внутренних нужд имеется.
Выбирался в т.ч. по географическому принципу: там стоит часть системы мониторинга, которая не должна стоять в одном ДЦ с продакшеном.
Цена меня устраивает, по качеству: да, с сетью тоже проблемы периодически бывают, сервер иногда зачем-то перезагружается, есть баги в панели управления, лично мне не приходит уведомление о том, что баланс подходит к нулю.
Но ИМХО вполне стоит своих денег, саппорт отзывчивый (если через helpdesk, телефон не отвечает) — мне настраивали «персональную конфигурацию» ВМ в xen'е.
Вообще, складывается впечатление, что его админит один человек (он же руководитель и т.д.), есть пара человек на первой лини саппорта.
Рекламировать для серьёзного продакшена не буду, но для каких-то других нужд не плохо.
У меня на hostink.ru тоже виртуальный сервер для внутренних нужд имеется.
Выбирался в т.ч. по географическому принципу: там стоит часть системы мониторинга, которая не должна стоять в одном ДЦ с продакшеном.
Цена меня устраивает, по качеству: да, с сетью тоже проблемы периодически бывают, сервер иногда зачем-то перезагружается, есть баги в панели управления, лично мне не приходит уведомление о том, что баланс подходит к нулю.
Но ИМХО вполне стоит своих денег, саппорт отзывчивый (если через helpdesk, телефон не отвечает) — мне настраивали «персональную конфигурацию» ВМ в xen'е.
Вообще, складывается впечатление, что его админит один человек (он же руководитель и т.д.), есть пара человек на первой лини саппорта.
Рекламировать для серьёзного продакшена не буду, но для каких-то других нужд не плохо.
За такие деньги можно арендовать только сервер в США.
Сервер в США это пинги по 100-150 мс, и у некоторых провайдеров — ограничения по скорости.
Т.е. это не всем подходит.
Сервер в США это пинги по 100-150 мс, и у некоторых провайдеров — ограничения по скорости.
Т.е. это не всем подходит.
За эти деньги можно у digitalocean взять впс на KVM
Только с одним «но» — с ограничением по трафику, что не для всех приемлимо.
Делал для пауков поисковиков и зарубежных посетителей специальный vps «за бугром» для статики, это кардинально снимает нагрузку по трафику для основного сервера.
Я, может, сейчас ерунду спрошу, но тем не менее — а чем fail2ban плох для защиты от брутфорса?
Спасибо, хороший туториал для начинающих. Мне было интересно читать, узнал кое-что новое. Жду второй части.
А почему Вы не используете штатный iptables-persistent из репозитория для сохранения и загрузки правил фаервола, а пишете свой скрипт?
Очень хотелось бы подобный материал по настройке сервера под задачу парсинга большого количества информации в интернете. Там важен тюнинг сетевых параметров ядра, правильный keep-alive, оптимальное кэширование dns запросов, полезные советы по использованию libcurl (как вот тут, но только посвежее).
а почему putty, а не xshell, который бесплатен для личного использования и куда стабильнее этой недопрограммы с названием putty
Полезно создавать пользователей с --disabled-password и заливать ssh key. Это надежнее, чем вход по паролю.
И чем wget провинился?
В комментарии к конфигурации nginx говорится о настройке slimits, однако самой настройки нет.
limit_zone slimits $binary_remote_addr 5m;
limit_conn slimits 20;
Я считаю, что применение Prelink при таком объеме памяти неразумно. Тем более на веб-сервере, когда все службы уже загружены, а ФС итак делает свое дело.
Мне кажется, для тестовых целей есть vds за $10-15 (за год!). Например (тут, о панели и плюшках тут ).
Искренне не понимаю почему тут пиарят сильно более дорогой и гораздо более лаговый* DO (глючность вылезает, когда на DO мониторинг ставишь, так они вполне ничего)
*)если кому-то интересен конкретный аргумент (с логами и т.д), пишите в ЛС. Я принципиально публично не выкладываю такие веши.
Искренне не понимаю почему тут пиарят сильно более дорогой и гораздо более лаговый* DO (глючность вылезает, когда на DO мониторинг ставишь, так они вполне ничего)
*)если кому-то интересен конкретный аргумент (с логами и т.д), пишите в ЛС. Я принципиально публично не выкладываю такие веши.
Хм. Запрещены ссылки на аудио/видео (правила). Т.е. сайт может быть «закрыт, если один из пользователей разместит на сайте ссылку на пиратский контент»? :)
Контент, размещенный на сайтах и VDS пользователей (в том числе размещённый посетителями сайта) не должен нарушать законов США и Германии. В частности, запрещены: расизм в любой форме; сайты, имеющие отношение к терроризму, а также другой нелегальный контент (например, контент, защищённый авторскими правами, при отсутствии у пользователя прав на распространение такого контента). Примеры нелегального контента: взломанное программное обеспечение, ключи к программным продуктам, программы «для взлома» или другой незаконной активности, медиа файлы (.mp3, .avi), а также ссылки на подобный контент.
Я тоже спрашивал. Есть категория правообладателей, к нарушению прав которых у ДЦ zero-tolerance (так как видимо есть примеры исков). На остальных в общем-то все решается мирно и неспешно.
DMCA в америке, кстати, так и работает.
Бывает и хуже, рэкспейс, например, меня постоянно блокирует просто за то, что «аккаунт управляется из России».
Приходится им звонить и выяснять что за фигня.
Бывает и хуже, рэкспейс, например, меня постоянно блокирует просто за то, что «аккаунт управляется из России».
Приходится им звонить и выяснять что за фигня.
Для тестовых целей лучше виртуалку завести, дешевые VPS (их, кстати, навалом) могут вести себя непредсказуемо — банально сложно понять, где-то неправильно настроено, или просто VPS глючит. У меня есть один такой за $19 в год — стоит выключенный потому, что на работающем сервере в любой момент могло отвалиться все что угодно, даже ssh.
Здесь явно не последнюю роль играла цена сервера. Искренне рекомендую пойти к www.digitalocean.com — возьмите самый дешевый вариант ($5, это на всего чуть дороже ваших 150 руб/мес), но Вы получите сумасшедшую общую машины скорость из-за быстрого диска, 512 Мб ОЗУ. При создании укажите ДЦ в Амстердаме — и будет он летать едва ли не быстрее иных московских ДЦ.
Гайд неплохой. По крайней мере (как все подобные тексты) это очень неплохое начало для сам-себе-админа, дающее возможность почувствовать себя хоть насколько-то полным хозяином на сервере. Спасибо Вам!
Гайд неплохой. По крайней мере (как все подобные тексты) это очень неплохое начало для сам-себе-админа, дающее возможность почувствовать себя хоть насколько-то полным хозяином на сервере. Спасибо Вам!
Ну ладно, а?
Только что специально проверил:
— пинги на любой из моих московских серверов — 17-19ms. При том, что я сейчас не в мск даже.
— пинги на DO амстердам — 70-75
— NY — 150 +-
— SFO — 215+-
Думаю, разница существенная… То есть, летать быстрее он точно не станет.
Да, в мск проверял релком и ЦТ. сервера лежат железные, colo.
Хотя, признаюсь, сначала решил сгонять купить попробовать, что там за такие деньги дают 8-)
Только что специально проверил:
— пинги на любой из моих московских серверов — 17-19ms. При том, что я сейчас не в мск даже.
— пинги на DO амстердам — 70-75
— NY — 150 +-
— SFO — 215+-
Думаю, разница существенная… То есть, летать быстрее он точно не станет.
Да, в мск проверял релком и ЦТ. сервера лежат железные, colo.
Хотя, признаюсь, сначала решил сгонять купить попробовать, что там за такие деньги дают 8-)
Да что «ладно». И в России, и в мире по-разному на VPS бывает… Я видел и такие пинги, как у Вас, а видел и заметно худшие. Иногда, кстати, задержка плавала в сутки так, что, видно, соседние VPS-ки выжирали канал не по-детски. Видел даже региональных операторов, которые пинги пропускали на канале вперед, чтобы пинг до Мск от них был лучше, чем у конкурентов :)
Железные сервера — своя специфика. Машину к тем же Storedata — и вперед, до любой точки России очень неплохо будет. Но вот как коснешься VPS, надо внимательно смотреть: чтобы ресурсов хватало, чтобы диски тянули, чтобы каналы были с запасом. DO по совокупности показателей — весьма и весьма держатся.
К кому в России на VPS пойти, чтобы диск не тормозил (т.е. было бы, как у DO) — ума не приложу, честно. За 10-20 тыс в мес отличную машину где взять и куда поставить — это легко, а вот 150 руб/мес и радоваться — с эти тяжко ).
Железные сервера — своя специфика. Машину к тем же Storedata — и вперед, до любой точки России очень неплохо будет. Но вот как коснешься VPS, надо внимательно смотреть: чтобы ресурсов хватало, чтобы диски тянули, чтобы каналы были с запасом. DO по совокупности показателей — весьма и весьма держатся.
К кому в России на VPS пойти, чтобы диск не тормозил (т.е. было бы, как у DO) — ума не приложу, честно. За 10-20 тыс в мес отличную машину где взять и куда поставить — это легко, а вот 150 руб/мес и радоваться — с эти тяжко ).
Ага, понял. спасибо за инфо.
Надо будет купить мелочевку на попробовать.
Просто я как-то на собственных железных серверах всю жизнь, хоть там и не 20, и даже совсем не 10 в месяц, но все равно, VDS, конечно, значительно дешевле выглядит.
Надо будет купить мелочевку на попробовать.
Просто я как-то на собственных железных серверах всю жизнь, хоть там и не 20, и даже совсем не 10 в месяц, но все равно, VDS, конечно, значительно дешевле выглядит.
> я как-то на собственных железных серверах
Да та же ерунда )) другой мир у них )
Но под мелочевку, правда, лучше брать мелочь вроде VPS. Они уже быстры, железо под ними неплохое — все реже есть смысл арендовать сервер за 4-5 тыс. против машины за 150-450 руб в мес.
Попробуйте. Они там вроде даже тест давали (я не пользовался тестом, правда), так что… И снапшоты у них хороши, тоже плюс.
Да та же ерунда )) другой мир у них )
Но под мелочевку, правда, лучше брать мелочь вроде VPS. Они уже быстры, железо под ними неплохое — все реже есть смысл арендовать сервер за 4-5 тыс. против машины за 150-450 руб в мес.
Попробуйте. Они там вроде даже тест давали (я не пользовался тестом, правда), так что… И снапшоты у них хороши, тоже плюс.
А кто-то насчет — www.transip.eu/vps/pricing-and-purchase/ может что-то сказать?
Я пробовал, киви-карту не приняли, оплатил электронной визой местного банка, через сутки пришло письмо что мои данные подозрительные, пришлите сканы паспорта, отправил им, через 6ть дней впс заблокировали, на вопрос в чем дело — написали что я им не присылал сканы, пришлите таким же способом.
Каждый ответ техподдержки не менее 50мин ждать. Дискового места дают много, но судя по скорости простые sata-винты. Процессора дают немного больше чем в DO. Систему накатываешь сам через KVM. Последующие месяцы оплата за vps в два раза выше (первый месяц промо), в итоге не особо и дешево, учитывая и цены в Евро. Находятся похоже в Нидерландах.
Вот такой опыт.
Каждый ответ техподдержки не менее 50мин ждать. Дискового места дают много, но судя по скорости простые sata-винты. Процессора дают немного больше чем в DO. Систему накатываешь сам через KVM. Последующие месяцы оплата за vps в два раза выше (первый месяц промо), в итоге не особо и дешево, учитывая и цены в Евро. Находятся похоже в Нидерландах.
Вот такой опыт.
По ссх скажу, что рута закрываю вообще, авторизируюсь только по ключу. Больше ничего не надо пока-что.
ОЗУ 128mb
Debian 7.0 x86-64
И сразу вопрос — why?
32битной системы у хостера не было? В данном случае разница в потреблении памяти будет приличной.
Если навязывать продумывать свою типовую конфигурацию nginx, то мне кажется необходимо включить в конфиг статьи запреты доступа к .htaccess и .svn
Для новичков хорошая статья, да и для себя дабы не забыть тоже! Небольшая поправка:
думаю
-l, --listening
Show only listening sockets.
На всякий случай посмотрим открытые порты:
netstat -tupln | grep LISTEN
думаю
| grep LISTEN будет здесь лишним, ибо в man-е сказано:-l, --listening
Show only listening sockets.
Странное дело, пишете, что это «прокачка» debian, а по факту с первых же строк описываете исправление «кривой» базовой установки ОС вашего хостера. Так и напишите в заголовке, что мол «исправляем косяки установки и подкачиваем Debian у %мой_хостер%».
теперь по порядку:
1) если уж сразу делаете "# apt-get update && apt-get dist-upgrade", то делайте лучше "# apt-get update && apt-get dist-upgrade && apt-get autoremove && apt-get autoclean"
2) зачем вы добавляете явно пользователя в sudoers, когда для этого есть специальная группа. И явно она создана не только для того, чтобы «пусть будет». хотя об этом написали выше.
ведь явно проще написать «usermod -a -G sudo username», чем ваши манипуляции с sudoers (в случае с ALL)
3) про отключение IPv6. лучше не просто отключить у SSH, но и вырубить целиком. за сим бежим сюда (http://wiki.debian.org/DebianIPv6#How_to_turn_off_IPv6)
4) лучше не «перелогиниваться», а не закрывая текущую сессию открыть новую, тем самым проверив что новые настройки пашут и потом уже закрывать старую сессию. а в случае с настройкой firewall вообще настроить «откат» правил по крону «на случай ядерной войны».
5) вместо дописывания источников в sources.list, лучше класть их отдельными файлами в sources.list.d — так и включать/выключать проще и искать какие выши репы добавленные, а какие «системные». то же самое с правкой конфига nginx — вместо nginx.conf кладём в conf.d (о чём в самом nginx.conf говорит строчка «include /etc/nginx/conf.d/*.conf;»
6) вместо "$ sudo iptables-save >/etc/firewall.conf" пишите '$ sudo su -c «iptables-save > /etc/firewall.conf»', тогда будет хватать прав.
теперь по порядку:
1) если уж сразу делаете "# apt-get update && apt-get dist-upgrade", то делайте лучше "# apt-get update && apt-get dist-upgrade && apt-get autoremove && apt-get autoclean"
2) зачем вы добавляете явно пользователя в sudoers, когда для этого есть специальная группа. И явно она создана не только для того, чтобы «пусть будет». хотя об этом написали выше.
ведь явно проще написать «usermod -a -G sudo username», чем ваши манипуляции с sudoers (в случае с ALL)
3) про отключение IPv6. лучше не просто отключить у SSH, но и вырубить целиком. за сим бежим сюда (http://wiki.debian.org/DebianIPv6#How_to_turn_off_IPv6)
4) лучше не «перелогиниваться», а не закрывая текущую сессию открыть новую, тем самым проверив что новые настройки пашут и потом уже закрывать старую сессию. а в случае с настройкой firewall вообще настроить «откат» правил по крону «на случай ядерной войны».
5) вместо дописывания источников в sources.list, лучше класть их отдельными файлами в sources.list.d — так и включать/выключать проще и искать какие выши репы добавленные, а какие «системные». то же самое с правкой конфига nginx — вместо nginx.conf кладём в conf.d (о чём в самом nginx.conf говорит строчка «include /etc/nginx/conf.d/*.conf;»
6) вместо "$ sudo iptables-save >/etc/firewall.conf" пишите '$ sudo su -c «iptables-save > /etc/firewall.conf»', тогда будет хватать прав.
6) Ещё так можно sudo iptables-save | sudo tee /etc/firewall.conf
1) При чистой установке обычно чистить нечего, но учту.
2) Исправил, спасибо.
3) Это под 6-ку, на 7-ой не проканает, в следующей статье я опишу способ.
4) TODO fix
5) Насчет sources не критично, при чистой установке там всего несколько строк, обычно просто отмечаю комментариями. p.s. для меня лично удобнее нагляднее иметь 1 файл.
6) Не проканало
2) Исправил, спасибо.
3) Это под 6-ку, на 7-ой не проканает, в следующей статье я опишу способ.
4) TODO fix
5) Насчет sources не критично, при чистой установке там всего несколько строк, обычно просто отмечаю комментариями. p.s. для меня лично удобнее нагляднее иметь 1 файл.
6) Не проканало
$ sudo su -c «iptables-save > /etc/firewall.conf»
-bash: /etc/firewall.conf»: Отказано в доступе1) ну вы же делаете на чистой установке dist-upgrade для чего-то) за той же целью и autoremove/autoclean
3) буквально на днях ставил 7-ку всё нормально прошло. хотя, вроде бы ещё что-то делал. надо бы проверить…
6) кхм. у меня выполняется нормально:
— borz@server:~$ sudo su -c "/sbin/iptables-save > /etc/firewall.conf"
borz@server:~$ l /etc/firewall.conf
/etc/firewall.conf
—
3) буквально на днях ставил 7-ку всё нормально прошло. хотя, вроде бы ещё что-то делал. надо бы проверить…
6) кхм. у меня выполняется нормально:
— borz@server:~$ sudo su -c "/sbin/iptables-save > /etc/firewall.conf"
borz@server:~$ l /etc/firewall.conf
/etc/firewall.conf
—
zram стоит по дефолту в дистрах на последних ядрах
Пруф в студию!
В ядро, возможно, добавлено, но почему-то в Ubuntu, даже последнюю, везде его надо ставить.
Про то, что установлено по умолчанию, нашел только Lubuntu 13.10 , и то, как я понимаю, они еще думают.
В ядро, возможно, добавлено, но почему-то в Ubuntu, даже последнюю, везде его надо ставить.
Про то, что установлено по умолчанию, нашел только Lubuntu 13.10 , и то, как я понимаю, они еще думают.
Сразу по пунктвм:
1. Для избежания длинного диалога useradd имеет массу параматров. Это позволяет сразу создать пользователя с необходимыми параметрами.
2. Про sudo молчу — хозяин-барин. :)
3. При настройке SSH в первую очередь нужно перейти на авторизацию по RSA!
Это аксиома.
4. В Nginx нет необходимости настраивать параметр use. Nginx выбирает его автоматом.
5. Iptable так не настраивают, есть более безопасные механизмы — сначала создается файл правил, затем проверяется, и только потом включается. Это так — лирика.
5. По поводу swappiness — я, по рекомендации IBM использую
vm.swappiness = 0
vm.vfs_cache_pressure = 100
хотя по этому вопросу сколько админов — столько мнений.
1. Для избежания длинного диалога useradd имеет массу параматров. Это позволяет сразу создать пользователя с необходимыми параметрами.
2. Про sudo молчу — хозяин-барин. :)
3. При настройке SSH в первую очередь нужно перейти на авторизацию по RSA!
Это аксиома.
4. В Nginx нет необходимости настраивать параметр use. Nginx выбирает его автоматом.
5. Iptable так не настраивают, есть более безопасные механизмы — сначала создается файл правил, затем проверяется, и только потом включается. Это так — лирика.
5. По поводу swappiness — я, по рекомендации IBM использую
vm.swappiness = 0
vm.vfs_cache_pressure = 100
хотя по этому вопросу сколько админов — столько мнений.
swap на OVZ не получится поставить, только на XEN.
Немного подрадактировал статью, исправил ошибки и кое-где дополнил. Проверил на debian 8.1 — работает. Новая статья откладывается на n-ое время…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прокачка debian/ubuntu сервера для маленьких