Если кто-то прочитал ссылки — там идет исследование «consumer-серии железа».
На фотке я так же вижу кусок несерверного железа. Так о каком ECC сейчас речь? О какой статистике по винтам, если это SATA? Саташные винты вообще не рекомендуются к использованию в production.
Мой совет: s/сервер/pc + не делать таких глобальных выводов основываясь на данных которым больше 3/5 лет
jreypo.wordpress.com — Неплохая подборка статей на тему unix(hp-ux в основном) и виртуализации.
omasse.blogspot.com — Technical blog about HP-UX, VMware ESX, SANs, Blade Servers and other similar subjects.
communities.vmware.com/community/vmtn — VMTN – VMware Technology Network
anticisco.ru — Годный ресурс по цискам.
scribd.com — Онлайн хранилище документов(довольно часто можно найти готовые решения или уже созданную документуху)
tools.ietf.org — Коллекция rfc + много чего еще
ripe.net — Думаю в пояснениях не нуждается
Я пару лет назад крутил Mikrotik — впечатления не лучшие остались, хотя может быть что-то и изменилось с тех порт.
А чем вам Lynksys + wrt не нравиться? Мне в плане железа линксисы больше импонируют. С софтом родным у них конечно проблема, особенно если нужно что-то мультикастовое стримить, но tomatousb или wrt решают большую часть проблем(по крайней мере на моем 4200 так и есть).
Одновременное выкачивание скрипта и выполнение его подсетью привидет к а) ботлнеку на сети б) резкому росту нагрузки на железо.
Мой совет — сразу после удачной сдачи сессии почитайте что такое SNMP. Также я бы посоветовал настроить syslog коллектор + splunk. Если после этого не наиграетесь, попробуйте сделать nagios + centreon + nagvis. После этого — покрутите заббикс, cacti итд. А после этого — идите уже куда-нибудь работать — там получите нормальные таски, которые нужно решать, там и sh прокачаете и bash если захотите, да и perl-а хлебнете.
1 — Система мониторинга на BASH, но через пару абзацев apt-get install perl.
2 — sudo chmod 777 — вас давно не били?
3 — «Проект опенсурсный» вы его где-то запаблишили под нормальными лицензиями? Если нет — не тешьте себя призрачными надеждами.
4 — Откройте же для себя snmp.
Ну и естественно — зачем же изобретать новый велосипед, если можно погнуть старый? Что принципиально нового дает ваша система? Вы меня не убедили.
Если уж на то пошло, то большинство знакомых мне телекомов замечательно проводят работы в районе 2-6 часов ночи, про дневное время даже речи быть не может. А по поводу пятницы после обеда — это скорее правило любящих побухать эникеев, которым главное с работы свалить пораньше.
> USB разъём одинаков по размеру с Eternet разъёмом. Не подключайте вслепую
Лолшто?
> Не выполняйте обновлений и критических изменений в пятницу после обеда/
Почему тег телекомы? Плановые работы как раз и нужно проводить перед выходными, чтобы в случае косяка было время все исправить без истерик.
1 — А вот это кстати довольно спорный момент — во время работы на одном белорусском сотовом операторе я был вынужден проводить аудит юниксовых серверов. Так вот был там один такой оракловый кластер, к которому кто-то снатил 22 порт. И в итоге раз в минуту туда шел коннект по ssh откуда-то из-за великого китайского файрволла. Я думаю, что никто не застрахован от такой ошибки.
Или же допустим внутри dmz была сломана машинка на которой крутился VHCS для каких-то там хостинговых целей — если бы не снорт, думаю можно было огрести реальных проблем.
2 — Из последнего — настраивал я с пол-года назад atlassian стек для одной конторы. Эти продукты использовали mysql. Ставил как было написано в мануале. После завершения инсталяции я там радостно ревоукнул половину прав(вот счас уже и не вспомню, что именно). Ругалась соотвественно только jira, а всякие fisheye, confluence и прочее — радостно продолжили работать. С одной стороны это все черевато проблемами и кучей потраченого времени на тюнинг, но с другой стороны — насколько приятнее на душе, когда ты знаешь, что у тебя все вылизано до предела.
По поводу лэтенси — сложно сказать для малых баз это может быть безразлично, но на нагруженых — это не так. В любом случае — база должна висеть на быстром диске(очень быстром :) )Навряд ли целесообразно заниматься страйпингом для /var что-то там. Опять же — если это nas, das или еще -то что внешнее — скорее всего есть возможность адаптивной оптимизации либо же снапшотов и прочих вкусностей, что также бывает очень полезно. (ну это уже совсем не безопасность).
А вообще — нет предела совершенству: Если есть время и есть деньги — виртуалки с разделением по сервисам + dmz с IDS или уже стразу IPS, но это уже совсем другая история, и такие телодвижения требуют значительно больших трудозатрат, чем перенос сервиса на другие порты.
Для меня было очень познавательным выкидывание виртуальной машинки со снортом в интернет с днс записью admin.xxx.com. Божымой — чего я там насмотрелся.
1 — Ну с одной стороны да — вроде бы перевешивание портов — дело крайне не обязательное, но в плане безопасности все просто:
В случае каких-то косяков — первым делом ломиться будут по стандартным портам. В купе с логированием трафика — очень просто отследить, кто и откуда ломиться посмотреть нашу базу(пару раз я вылавливал таких интересующихся в совершенно неожиданных местах).
2 — Тут тоже спорный вопрос по поводу прав — лично я видел довольно мало приложений, которым требуется дроп итд. Я предпочитаю забирать права на удаление, и отлавливать ошибки в логах — если есть ошибки и они по делу — тогда да — можно разрешить.(абсолютно аналогично я поступаю и с правами на файлы — давая минимальные права на группу, забирая право владения у пользователя).
3 — Немного не так — я просмотрел в статье, что настраивается биндинг на ip. Просто к этому я бы еще добавил лог на 127.0.0.1 на необходимый порт, тк правильная ситуация — когда подключение идет с внешнего Ip, а не через шелл на сервере :)
4 — Грубо говоря да. Тут еще довольно неосвещенный момент — обычно для баз, лично я использую отдельную хранилку, лун, раздел и прочее чтобы разделять I/O системы и базы.
P.S. Вообще спасибо за проявленный интерес — я думаю, если добавить вышеприведенные ссылки, ваш топик будет крайне содержателен и полезен.
Вообще-то если уж на то пошло, то я бы сделал следующее:
1 — Перевесить Mysql на другой порт. При этом все, что ломиться на стандартный — в лог iptables.
2 — Права на БД — сразу минимальные. Потом поднимать в случае возникновения ошибок.
3 — Убрал бы вообще mysql с 127.0.0.1 — у меня на всех серверах стоит лог+дроп всего, что идет на localhost.
4 — Ну и да — саму базу я бы перенес на отдельный раздел(проще всего и удобнее всего — симлинком) + изменение имени пользователя.
А можно мне для расширения кругозора уточнить — а на каких более продвинутых уровнях это обсуждается? Просто всегда хотел получить систематизированные и глубокие знания о сетях, но как то не удалось.
И кстати по поводу CCNA — а насколько глубоко там изучают EIGRP?
Прошу прощения, если я грубовато выразился, но я думаю, что статья скорее вредная, чем полезная, т.к. вы показываете дурной пример. По крайней мере вам следовало бы добавить в статью информацию о том, как ПРАВИЛЬНО решить проблему, а не создавать подпорку, которая потом может чем-то аукнуться.
На фотке я так же вижу кусок несерверного железа. Так о каком ECC сейчас речь? О какой статистике по винтам, если это SATA? Саташные винты вообще не рекомендуются к использованию в production.
Мой совет: s/сервер/pc + не делать таких глобальных выводов основываясь на данных которым больше 3/5 лет
Я думаю, что это основная мысль поста. Все! Больше ничего не надо. Админ разрешил трансферить зону кому попало — это его проблема.
Это то же самое, что давать root access на любой публичный ip с паролем qwerty.
omasse.blogspot.com — Technical blog about HP-UX, VMware ESX, SANs, Blade Servers and other similar subjects.
communities.vmware.com/community/vmtn — VMTN – VMware Technology Network
anticisco.ru — Годный ресурс по цискам.
scribd.com — Онлайн хранилище документов(довольно часто можно найти готовые решения или уже созданную документуху)
tools.ietf.org — Коллекция rfc + много чего еще
ripe.net — Думаю в пояснениях не нуждается
А чем вам Lynksys + wrt не нравиться? Мне в плане железа линксисы больше импонируют. С софтом родным у них конечно проблема, особенно если нужно что-то мультикастовое стримить, но tomatousb или wrt решают большую часть проблем(по крайней мере на моем 4200 так и есть).
Мой совет — сразу после удачной сдачи сессии почитайте что такое SNMP. Также я бы посоветовал настроить syslog коллектор + splunk. Если после этого не наиграетесь, попробуйте сделать nagios + centreon + nagvis. После этого — покрутите заббикс, cacti итд. А после этого — идите уже куда-нибудь работать — там получите нормальные таски, которые нужно решать, там и sh прокачаете и bash если захотите, да и perl-а хлебнете.
2 — sudo chmod 777 — вас давно не били?
3 — «Проект опенсурсный» вы его где-то запаблишили под нормальными лицензиями? Если нет — не тешьте себя призрачными надеждами.
4 — Откройте же для себя snmp.
Ну и естественно — зачем же изобретать новый велосипед, если можно погнуть старый? Что принципиально нового дает ваша система? Вы меня не убедили.
Лолшто?
> Не выполняйте обновлений и критических изменений в пятницу после обеда/
Почему тег телекомы? Плановые работы как раз и нужно проводить перед выходными, чтобы в случае косяка было время все исправить без истерик.
Или же допустим внутри dmz была сломана машинка на которой крутился VHCS для каких-то там хостинговых целей — если бы не снорт, думаю можно было огрести реальных проблем.
2 — Из последнего — настраивал я с пол-года назад atlassian стек для одной конторы. Эти продукты использовали mysql. Ставил как было написано в мануале. После завершения инсталяции я там радостно ревоукнул половину прав(вот счас уже и не вспомню, что именно). Ругалась соотвественно только jira, а всякие fisheye, confluence и прочее — радостно продолжили работать. С одной стороны это все черевато проблемами и кучей потраченого времени на тюнинг, но с другой стороны — насколько приятнее на душе, когда ты знаешь, что у тебя все вылизано до предела.
По поводу лэтенси — сложно сказать для малых баз это может быть безразлично, но на нагруженых — это не так. В любом случае — база должна висеть на быстром диске(очень быстром :) )Навряд ли целесообразно заниматься страйпингом для /var что-то там. Опять же — если это nas, das или еще -то что внешнее — скорее всего есть возможность адаптивной оптимизации либо же снапшотов и прочих вкусностей, что также бывает очень полезно. (ну это уже совсем не безопасность).
А вообще — нет предела совершенству: Если есть время и есть деньги — виртуалки с разделением по сервисам + dmz с IDS или уже стразу IPS, но это уже совсем другая история, и такие телодвижения требуют значительно больших трудозатрат, чем перенос сервиса на другие порты.
Для меня было очень познавательным выкидывание виртуальной машинки со снортом в интернет с днс записью admin.xxx.com. Божымой — чего я там насмотрелся.
В случае каких-то косяков — первым делом ломиться будут по стандартным портам. В купе с логированием трафика — очень просто отследить, кто и откуда ломиться посмотреть нашу базу(пару раз я вылавливал таких интересующихся в совершенно неожиданных местах).
2 — Тут тоже спорный вопрос по поводу прав — лично я видел довольно мало приложений, которым требуется дроп итд. Я предпочитаю забирать права на удаление, и отлавливать ошибки в логах — если есть ошибки и они по делу — тогда да — можно разрешить.(абсолютно аналогично я поступаю и с правами на файлы — давая минимальные права на группу, забирая право владения у пользователя).
3 — Немного не так — я просмотрел в статье, что настраивается биндинг на ip. Просто к этому я бы еще добавил лог на 127.0.0.1 на необходимый порт, тк правильная ситуация — когда подключение идет с внешнего Ip, а не через шелл на сервере :)
4 — Грубо говоря да. Тут еще довольно неосвещенный момент — обычно для баз, лично я использую отдельную хранилку, лун, раздел и прочее чтобы разделять I/O системы и базы.
P.S. Вообще спасибо за проявленный интерес — я думаю, если добавить вышеприведенные ссылки, ваш топик будет крайне содержателен и полезен.
1 — Перевесить Mysql на другой порт. При этом все, что ломиться на стандартный — в лог iptables.
2 — Права на БД — сразу минимальные. Потом поднимать в случае возникновения ошибок.
3 — Убрал бы вообще mysql с 127.0.0.1 — у меня на всех серверах стоит лог+дроп всего, что идет на localhost.
4 — Ну и да — саму базу я бы перенес на отдельный раздел(проще всего и удобнее всего — симлинком) + изменение имени пользователя.
GRANT ALL ON foo.* TO bar@192.168.1.10 IDENTIFIED BY 'mypassword'
И кстати по поводу CCNA — а насколько глубоко там изучают EIGRP?
Прошу прощения, если я грубовато выразился, но я думаю, что статья скорее вредная, чем полезная, т.к. вы показываете дурной пример. По крайней мере вам следовало бы добавить в статью информацию о том, как ПРАВИЛЬНО решить проблему, а не создавать подпорку, которая потом может чем-то аукнуться.