Переход с bash на zsh

Автор: admin от 15-04-2017, 18:40, посмотрело: 216

Чтобы перейти с bash на zsh необходимо знать базовые отличия между ними — без этого будет сложно провести первоначальную настройку zsh в ~/.zshrc.


Я не нашёл краткого описания этих отличий когда переходил сам, и мне пришлось потратить немало времени на вычитывание документации zsh. Надеюсь, эта статья упростит вам переход на zsh.


Зачем переходить


Для начала — а стоит ли вообще тратить своё время и внимание на переход? Учить ещё один диалект sh, менее распространённый чем POSIX sh или bash, заново заниматься настройкой рабочего окружения…


На мой взгляд, если вы проводите много времени в консоли, вам нравятся Vim или Emacs и вы уже потратили немало времени на их настройку "под себя" — однозначно стоит! Zsh по духу очень на них похожа: это очень сложная и гибкая программа, чьи возможности полностью мало кто знает, но потратив некоторое время на настройку можно получить очень удобную лично вам рабочую среду.

Категория: Операционные системы » Linux

 

Отказоустойчивый кластер для балансировки нагрузки

Автор: admin от 13-04-2017, 16:15, посмотрело: 153

Поговорим о горизонтальном масштабировании. Допустим, ваш проект вырос до размеров, когда один сервер не справляется с нагрузкой, а возможностей для вертикального роста ресурсов уже нет.

Категория: Программирование, Системное администрирование, Веб-разработка

 

Windows 10 Creators Update: что нового в Bash/WSL и Windows Console

Автор: admin от 13-04-2017, 15:15, посмотрело: 162

Когда вышел Windows 10 Anniversary Update (AU), подсистема Windows Subsystem for Linux (WSL) была ещё далека от завершения и страдала от многих несовместимостей, особенно с популярными средствами разработки вроде node.js, Java и др.

Однако было важно передать эту восхитительную новую функцию в руки реальных пользователей, чтобы мы могли узнать у них — у ВАС — что именно необходимо WSL, что работает, что не работает и т.д.

И сообщество ответило! :)

Таким образом, этот новый релиз подсистемы Windows для Linux и консоли Bash создан вами и для вас!

Категория: Системное администрирование, Windows, Linux, Ubuntu

 

Операторы для Kubernetes: как запускать stateful-приложения в кластере

Автор: admin от 13-04-2017, 14:10, посмотрело: 260

Проблема stateful-приложений в кластере


Конфигурация, запуск и дальнейшее масштабирование приложений и служб осуществляются просто, если речь идёт о случаях, классифицируемых как stateless, т.е. без сохранения данных. Такие сервисы удобно запускать в Kubernetes, пользуясь его стандартными API, потому что всё происходит «из коробки»: по стандартным конфигурациям, без привлечения какой-либо специфики и магии.

Проще говоря, для запуска в кластере из контейнеров ещё пяти копий бэкенда на PHP/Ruby/Python требуется лишь 5 раз поднять новый сервер и скопировать исходники. Поскольку и исходники, и init-скрипт лежат в образе, масштабирование stateless-приложения становится совсем элементарным. Как хорошо известно любителям контейнеров и микросервисной архитектуры, сложности начинаются для приложений категории stateful, т.е. с сохранением данных, таких как базы данных и кэши (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra…). Это касается как софта, самостоятельно реализующего кворумный кластер (например, Percona XtraDB и Cassandra), так и софта, требующего отдельных управляющих утилит (такого, как Redis, MySQL, PostgreSQL…).

Сложности возникают по той причине, что исходников и запуска сервиса становится не достаточно — нужно выполнить еще некоторые действия. Как минимум — скопировать данные и/или присоединиться к кластеру. А если точнее, то эти сервисы требуют понимания, как их правильно масштабировать, обновлять и переконфигурировать без потери данных и их временной недоступности. Учёт этих потребностей и называется «эксплуатационными знаниями» (operational knowledge).

Категория: Программирование, Системное администрирование

 

Технологии песочниц. Check Point SandBlast. Часть 3

Автор: admin от 12-04-2017, 13:10, посмотрело: 214

Технологии песочниц. Check Point SandBlast. Часть 3

Ну вот мы и добрались до заключительной части. С предыдущими можно ознакомиться здесь (первая, вторая). Мы продолжаем тему защиты от таргетированных атак. Мы уже обсудили каким образом можно защититься на уровне сети, в частности периметра организации. Однако в современном мире этого недостаточно. На этот раз мы поговорим о защите компьютеров пользователей.

Периметр


Понятие “периметра” становится весьма условным и трудно различимым. Практически все ресурсы сети Интернет переходят на защищенный https протокол. Это и почта и файловые хранилища, социальные сети, порталы документооборота. Т.е. передаваемые данные шифруются, что значительно осложняет их анализ на уровне сети. (Все современные NGFW обязаны иметь функцию https инспекции).

Практически у каждого сотрудника есть флешка на которой он приносит из дома файлы. С флешками могут приходить и ваши партнеры. Куда вставлялись эти флешки ранее и что на них сейчас, сказать очень трудно.

Личные смартфоны и ноутбуки. Эти устройства все чаще используются для рабочих целей. При этом тот же смартфон позволяет установить Интернет соединений посредством 3g или LTE.
В итоге, из-за перечисленных средств, мы имеем потенциальные дыру в нашей корпоративной сети, через которые злоумышленники обходят все наши сетевые средства защиты, какими бы крутыми (дорогими) и надежными они не были. Можно конечно запретить использование и флешек и личных смартфонов для работы, но очень часто это лишь вредит основному бизнесу.
Единственным разумным решением в данном случае будет организация дополнительного уровня защиты — защита компьютеров пользователей.

Категория: Программирование, Системное администрирование, Сетевые технологии

 

Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1

Автор: admin от 11-04-2017, 21:45, посмотрело: 137

Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1
Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.

IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.

Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:

  • RFC 791 – Internet Protocol

  • RFC 793 – Transmission Control Protocol

Категория: Linux, Сетевые технологии

 

Настоящий Unix — не есть приемлемый Unix

Автор: admin от 11-04-2017, 11:55, посмотрело: 112

Настоящий Unix — не есть приемлемый UnixКомандная строка Unix полна сюрпризов. Например, вы знали, что инструмент ls, который чаще всего используется для получения списка файлов в текущем каталоге, в версии OS X распознаёт не менее 38 разных флагов?

Я не знал, так что затвитил этот факт. И получил парочку ответов, один из которых заставил меня задуматься: действительно ли саму Unix нужно винить в этом?

Насколько я знаю, ни Linux, ни OS X не были спроектированы в строгом соответствии с философией Unix. Будет лицемерием основывать критику “Unix” только на этих производных от Unix, которые есть у нас сегодня.

Но я всё-таки попробую показать, как много проблем с интерфейсами командной строки в современных наследниках Unix восходят к корням самой Unix. В частности, я попытаюсь объяснить свой скепсис относительно идеи, что окружение командной строки Unix могло когда-либо поддерживать экосистему программ, каждая из которых хорошо выполняет одну функцию.

Но я немного опережаю события. Прежде чем я начну говорить об этом, давайте более пристально посмотрим на команду ls и попробуем выяснить, что конкретно она делает не так.

Категория: Программирование, Системное администрирование

 

Технологии песочниц. Check Point SandBlast. Часть 2

Автор: admin от 7-04-2017, 13:10, посмотрело: 453

Технологии песочниц. Check Point SandBlast. Часть 2
Продолжаем тему сетевых песочниц. В предыдущем модуле я уже привел небольшую “печальную” статистику целенаправленных атак. Резюмируя ранее сказанное, можно сделать несколько основных выводов:


  • 99% зловредов были замечены всего один раз. По этой причине сигнатруная защита просто бессильна.

  • Почта является излюбленным иснтрументом хакера. Как правило зловреды доставляются в виде файлов, либо ссылок на файлы.

  • Вопреки обыйденному мнению, заразными могут быть не только файлы типа exe, flash и java файлы. Т.е. запретив этот тип файлов, вы все еще не защищены. Зловред может быть спрятан в разрешенные документы такие как: doc, excel, pdf, powerpoint, архивы и так далее.

Категория: Программирование, Системное администрирование, Сетевые технологии

 

Создание приватной сети, или чайнаинтернету — нет, нет, нет

Автор: admin от 7-04-2017, 10:00, посмотрело: 99

Создание приватной сети, или чайнаинтернету — нет, нет, нет

С годами мы обрастаем компьютерами и девайсами, которые ещё иногда называют хостами. Например, один виртуальный хост висит в стране чистого интернета, есть хосты на работе, дома, на даче, и т. д. Хотелось бы иметь средство для управления всеми ими, чтобы можно было из любого места зайти в любое другое, в режиме командной строки, разумеется. Например, с дачи нам хотелось бы зайти на рабочий компьютер, а с работы — на хост чистого интернета и т. д. Но на нашем пути встают препятствия: хосты находятся за NATом, на работе нет прав администратора, а в чистый интернет нас и подавно не хотят пускать.

Что же делать?

Категория: Системное администрирование, Сетевые технологии

 

SystemD отстой, да здравствует SystemD

Автор: admin от 6-04-2017, 12:30, посмотрело: 115

Кажется, что systemd — некое яблоко раздора в Linux-сообществе. Как будто не существует нейтральной точки зрения на systemd. Кардинально противоположные мнения предполагают, что вы должны или любить его, или желать уничтожения. Я хочу предложить некую середину. Для начала, обсудим кошмарные свойства systemd.

Плохое и кошмарное


systemd-escape


Тот факт, что существует systemd-escape, сам по себе явно указывает на нечто ужасно неправильное. Если вы никогда не видели или не использовали эту команду в деле, считайте, что вам повезло.

Категория: Системное администрирование, Linux