Пользователи и права.

На кой мне другие пользователи? Мне и пользователя admin достаточно. И прав у него до фига.

Такая вот грешная мысль порождает много проблем.
Проблема №1 - права администратора дают неограниченные возможности тому, кто под ними работает. А работать за нас может троян или спам-бот. Или какая-нибудь зараза.
Проблема №2 - права администратора не требуются для частого использования.
Истина №1 - права администратора нужны для тяжелых системных действий. К примеру форматнуть диск или поставить сервер БД.
Истина №2 - каждый пользователь должен работать под своей учётной записью. Я же не думаю, что тебе хочется делиться своей информацией с кем-то ещё. Всякое бывает. "Ой, я тут случайно затер твой курсач".
Истина №3 - должен быть четкий, очерченный круг задач, для которых необходимы права администратора.

В общем, что касается форточек, то они тоже об этом думают. Не прошло и 10 лет, как их пользователь по умолчанию не админ и при этом удобно работать.

А кто админ в линухах? Да, тут есть такой пользователь root
Вот он круче всех. От его имени запускаются все базовые системные процессы. Именно этот пользователь способен одним махом похоронить систему. Причем реально отправить систему в аут. Но не все процессы в твоей системе будут идти от имени супер-пользователя. Если процессу не нужен доступ к каким-то специальным файлам или же он не открывает порты с 1 по 1024, то процесс скорее всего будет запускать под своим пользователем. И более того, если какой-то программе требуется только в определенных местах права супер-пользователя, то именно эти места можно наделить полномочиями супер-пользователя.
Т.е. получается, что права наделяют порционом и очень дозировано. Отсюда глобальное правило. Работать под рутом надо только тогда, когда это действительно требуется.
Правило №2 - старайся не давать доступ к пользователю root.
Правило №3 - если кто-то лишний узнал твой пароль от рута, то это очень большие проблемы. Т.к. этот человек способен в очень короткие сроки сделать из системы всё что угодно.

Т.ч. лучше создать себе пользователя и работать под ним. А делать это надо как-то так
useradd -m <имя пользователя> # создадим пользователя и каталог для него /home/<имя пользователя>
passwd <имя пользователя> # зададим пароль пользователю
passwd # поменяет пароль твоему текущему пользователю.
Кстати, при смене пароля просят старый пароль. Но супер-пользователь способен сменить все пароли  без вопросов.

Т.к. пользователи обычно объединяются в какие-либо группы, то и тут есть группы.
Обычно у каждого файла есть два параметра имя пользователя и пароль. И критерии что может делать с файлом пользователь(создатель), а что может с этим фалом делать конкретная группа, а так же что могут делать все остальные.
Так же пароль можно задать и группе, а так же можно сделать администраторов для группы. И вот об этом мало кто помнит.
Есть такая команда gpasswd. Например:
gpasswd -a <имя пользователя> <имя группы>  # добавить пользователя в группу

gpasswd -d <имя пользователя> <имя группы>  # удалит пользователя из группы

man gpasswd # много полезной информации

А где хранится вся информация, если что?
Хранится она в следующих файлах
/etc/passwd
/etc/shadow # может смотреть только root
/etc/group
/etc/gshadow # может смотреть только root

А как, спросишь ты, мне зайти под другим пользователем.
su
su root  # войдешь под супер-пользователем
если установлена утилита sudo и твой пользователь имеет соответствующий доступ, то
sudo -i # войдешь под супер-пользователем использую свой пароль.
sudo apt-get install mc # получишь права супер-пользователя для установки mc

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

Дальше я расскажу тебе про структура файлов и каталогов в системе.

Debian. Первые шаги.

Доброго времени суток, сегодня я начну рассказывать тебе о Debian.
В общем система не прихотлива и для начала нам нужно познакомиться с системой управления пакетами APT.

В принципе если в консоли ты наберешь apt+, то увидишь ряд программ по управлению пакетами.

Для начала нам нужна команда apt-get.

apt-get update - обновит списки пакетов в нашей системе. А если подробнее, то скачает файлы со списками свежих пакетов. Сопоставит, и обновит локальную информацию о пакетах.
apt-get safe-upgrade - часто делается после apt-get update (я думаю, что тебе это понятно). Производит обновление уже установленного по. Сам качает, сам устанавливает и иногда задает необходимые вопросы. NB:Вопросы надо читать очень внимательно.
apt-get install <название пакета>. Устанавливает пакет по его названию. К примеру:
apt-get install mc apache2 # Установит mc и веб-сервер апаче. А так же разрешит все зависимости по пакетам.


Что такое зависимость? Ситуация тут такая. Можно скомпилировать (собрать) пакет и внести в него все необходимые для работы библиотеки, а так же дополнительное ПО.  А можно сказать, что такие библиотеки и ПО лежат где-то в системе. И вот в системе этих библиотек может и не оказаться, в виндоузе этот вопрос в общем-то до сих пор толком не решен. В линухах этот вопрос уже успешно решен, причем в полной мере. И решен уже точно  больше 5 лет. Т.е. при создании пакета разработчик пишет, что его пакет зависит от таких-то библиотек или ПО, причем можно указать конкретные версии. И всё. Мы с тобой к этим проблемам практически не притрагиваемся.

Следующая команда нам тоже очень полезна:
apt-cache - позволяет искать пакеты и предоставляет исчерпывающую информацию по пакетам.
apt-cache search ^mc # будет искать все пакеты название или описание которых начинается на две буквы mc

а вообще по всем этим командам я рекомендую тебе прочитать руководство.
man apt-get
man apt-cache

Сразу отвечу тебе на твой вопрос, а где здесь setup.exe файлы? А вот их-то и  нет. Даже нет понятия исполняемого файла по расширению(.exe которое). Пакетные файлы обладают расширением deb. Их можно установить командой:
dpkg -i <имя файла>.deb
Вообще apt-get install сам скачает эти deb файлы и установит.

А вот тебе блэкджек и шл...плюшки:
apt-get install aptitude
aptitude

P.S.: Т.к. процесс установки пакетов часто требует доступ к глобальным библиотекам и программам в системе, то установка требует прав супер-пользователя root.
О том, кто это  и что у него за права я расскажу чуть позже.
  

Почему Debian

В общем линухов(подразумеваю ОСь) всяких много, и количество инсталляций идеи финского студента просто грандиозно.
Такое обилие, казалось бы, велосипедов порождает грандиозную возможность выбор под себя.
А если хотите, то можете и собрать под себя свой собственный дистрибутив с ядром линукс.
Есть много всякого, к примеру что кушал я:
Шляпы:
RHEL - она же шляпа
Fedore - красивая шляпа
centos - рабоче-крестьянская шляпа.

deb-based:
Debian - довольно популярная платформа для веб-серверов
Ubuntu - популярна на десктопах. Но есть и серверная версия

source-based:
arch-linux - настройки прикольные
gentoo - компилим всё что движется, всё что не двигается двигаем и компилим.
прим. - кушал многое другое, но не прижилось.

А если честно то все linux-based дистрибутивы можно поделить на два лагеря
Уже собранные (бинарные сборки) платформы и ещё не собранные.
В чем плюсы, а в чем минусы?
Если код уже собран, то его проще установить.
Из-за большей совместимости код собирают с довольно общими флагами. Меньше оптимизации, зато больше покрытие по железу и надежнее код. В принципе, чем сложнее флаги оптимизация, тем больше вероятность не собрать систему.
Вроде куча плюсов, а где минусы? А минусы в том, что если поэкспериментировать, то можно собрать систему конкретно под эту машину, с нужными флагами и получить за это бонус в виде производительности.
Ну и наоборот для source-base систем. К минусам сборки также стоит отнести то, что некоторые программы могут собираться довольно долго, особенно на слабом железе.
Примечание: время сборки каждой программы обычно считают в SBU. SBU - static bash unit или же время за которое собирается bash считается за единицу.

Для средних серверов я однозначно рекомендую бинарные сборки дистрибутивов. Т.к. смысла в увеличении скорости нет, а вот надежность сборки решает. Для себя я выбрал debian и вполне доволен. Конечно, между релизами дебиана проходит много времени, зато в принципе надежность на высоте.

А чем же отличаются бинарные сборки?
Обычно все сборки отличаются менеджером управления пакетами, своими репозитариями с версиями программ(как правило даже накладывают патчи), а так же конфигурационными файлами. Инсталлятором и базовым пакетом программ. И патчами наложенными на ядро. Да, именно так, сборки ядер между дистрибутивами часто отличается не только версией, но и  патчами к ядрам. В принципе сборка ядра вещи полезная и на глобальном уровнем этой технологией лучше овладеть.  Скорость ОС на прямую зависит от ядра. Чем больше в ядре не нужного, тем лучше. Идеальная сборка - в ядре есть только то, что есть в железе и ряд компонентов для ОСы. Но идеал достигать не стоит.
  

Первые шаги. Инструмент.

В общем я предпочитаю опенсорц и linux. Ну так исторически сложилось.
Что дает мне этот инструмент? А вот что:

• Простота в использовании - простые конфиги, море документации, комманда man. От себя добавлю, что знаю крайне мало комманд, наверное с пару десятков. Но самая главная из них - man
• Много полезного и бесполезного софта из коробки - т.е. мне не надо бегать по интернету в поисках очередной программы. Мне надо знать про apt и всё.
• Цена - критерий тоже важный. Да, я понимаю, что если у вас БД Оракл+банк, то конечно цена для вас не главное. А если у вас простой сайт? Или крупный online-проект?

Первые шаги. Изучить инструменты.

Представитель любой профессии скажет, что отношение качество/скорость работ зависит от инструмента. И так же скажут, что самое дорогое часто не самое лучшее. Значит и нам надо понять, что за инструменты нам нужны.

Наши инструменты - это программы и ОС. Без этого мы никуда не попадем.
Для того, что бы выбрать хороший инструмент, надо знать для чего мы его выбираем. Лично я выбираю инструмент по следующим признакам:
1. Наличие хорошей документации.
2. Хорошая управляемость.
3. Быстрая повторяемость
4. Журналирование инцидентов.

По поводу первого пункта думаю всё ясно. Нет документации - много магии. Проходить всю магию самому - сложно и долго. А значит, что дорого. Чем понятнее документация, чем подробнее она объясняет как и зачем, тем проще работать с инструментом.

Под вторым пунктом я подразумеваю простые и доступные формы настройки инструмента. Многие не задумываются над этим, и это часто вызывает ошибки. Тут варианта два. GUI администрирования (M$ like) или text-config style (nix like). Какие у них преимущества:
GUI:

• Удобство настроек - часто варианты выбора и пояснения к ним уже заданы (+)
• Отсутствует повторяемость (-)
• Нет механизма точных подстроек - если и есть, то интерфейс часто представляет из себя regedit из-за обилия настроек. (-)

Text:

• Начальная сложность в освоении - надо понимать, для чего каждая настройка. (-)
• Компактность параметров - все в одном месте (+)
• Точные подстройки прямо в файле. (+)
• Повторяемость (+)

Часто бывает так, что GUI администрирования, это лишь оболочка для редактирования какого-то набора файлов. Те кто видели редактор реестра M$ поймут, как не просто возиться с GUI.

Быстрая повторяемость.

Я не фанат "начального готового образа системы". А почему? А всё просто. Я знаю, что такое netinstall и как быстро и просто разворачивать любое кол-во машин. У образа есть косяки. Например время создания файлов из прошлого. Различные параметры будут совпадать, хотя на деле не должны. Образ стареет со временем. За ним приходиться следить. Очень много мусора накапливается, если система поддерживается и не факт, что со старым мусором мы не утянем зловреда.

Для сетевой инсталляции достаточно подготовить набор софта и файл ответов, а так же разместить набор конфигов. Инсталляция будет свежей.  

Журналирование инцидентов(логирование).

Собственно система логирования всего и вся.

Важные замечания к системе.

1. Возможность выбора уровня логирования.
2. Подробные настройки уровня логирования.
3. Удобное восприятие информации.
4. Централизованное логирование всего и вся.

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

По второму. Желательно иметь возможность каким-то способом указывать что хочется видеть в данных об инциденте.

По третьему. Это мы видим часто: "Ошибка №23. Обратитесь к администратору." Я сам администратор, и мягко говоря я не помню все кода.

Вот примеры минимально удобных ошибок "Ошибка 404. Страница не найдена."

Или из другой оперы "Ошибка 12. Сервер ключа не найден."

Тут понятно, какой-то сервер ключа не найден. Видимо нужен, но куда-то пропал.

А вот если лог был бы таким: "Ошибка 12. Сервер ключа по запросу ххх.ххх.ххх.ххх:3182 не найден". То уже информация интереснее.

И последнее, и самое важное. Я хочу иметь общий инструмент слежения за ошибка. По возможность, что бы журнал инцидентов от всех инструментов был бы в одном месте.

P.S.: чем больше не нужных вещей в инструменте, тем хуже он будет выполнять свою работу.

 

 

Первые шаги. Подумать.

Наверное, они самые важные.
Самый важный шаг - стать профессионалом и забыть всё как страшный сон. Но не всё сразу.
Вот некоторые тезисы, которые я воспринял и постараюсь донести до тебя:
1. Сесть и подумать, что ты хочешь.
2. Взять принцип разумной достаточности и при помощи него отфильтровать, что ты хочешь.
3. Поискать в сети, как делать то, что ты хочешь.
4. Поискать там же, а не сделали это уже за тебя.
5. Посмотреть, что уже сделано и пойти читать документацию.
6. Согласовать с общим планом работ.
7. Сделать.
А теперь подробнее.
Надо составить план того, что ты хочешь. А что ты хочешь? А хочешь ты просто и надежно, да так, что бы пользователям жить не мешало, а помогало. Вопрос цены как правило стоит и об этом следующий принцип.
Разумная достаточность.
Как я её определяю? А очень просто. Из выше описанного я смотрю что уже есть на рынке и для каких объемов. Сопоставляю с моими потребностями и ищу как мне это сделать за минимальные деньги. Расскажу на примере подбора серверной:
Задача:
Есть закуток (3.5х1.5) метра. Надо поставить несколько серверов и провести всю разводку с этажа. Кол-во розеток 20 шт. Сервера нужны: почта, шлюз, шара с авторизацией, веб, бд.
БД - отдельно, т.к. есть некоторые нагрузки.
Что нам нужно:

• Два сервера
• кондиционер
• дверь с ключем
• kvm
• коммутатор
• патч-панель
• ИБП.

Теперь два бюджета:
Первый.

• Два хороших сервера (HP, IBM, Fuji и т.д.). 
• Супер стойка. 
• Супер кондиционер дайкин.
• Офигенно дорогую циску,
• ИБП на 5kVA.
• Ну и бронированную дверь.
• Мелочевка.

Ну как солидно? Да! (+)
Дорого? Да! (-)
Необходимо? Нет! (-)
Надежно? Нет! (-)
Т.к. цена такой серверной вместе с серверами мягко говоря будет скакать к миллиону, то можно и подумать, над достаточным вариантом.
Достаточный:

• Сервера - 3 шт(один в избытке) из обычного офисного железа и корпуса не RM. 
• Два кондиционера с зимним блоком. Такие, что бы подешевле, но качественные(читаем отзывы других людей).
• Стойку нафиг, т.к. плотность никакая.
• УПС можно что-нибудь, не супер-пупер, а так, что бы 20 минут протащило два сервера и сеть на полной нагрузке, а также что бы была горячая замена батарей.
• Простой свич.

Что в итоге имеем? Сервера - до 80 т.р. за всё про всё. УПС - 20 т.р. кондиционеры - 50 т.р. свич и прочие радости - до 40 т.р. Около 200 т.р. на всё.
Солидно? Нет! (-)
Дорого? Нет! (+)
Необходимо? Да! (+)
Надежно? Да! (+)
Дальше искать в сети и не ... именно, не смотреть на рекламные проспекты. Мол у нас самое самое.
Пытайся понять, что достаточно тебе и какие вещи нужны именно тебе. Сразу оговорюсь на тему: "А вдруг резко будем расти? Надо же быть готовым". Ты гугл? Ну ладно, яндекс? Как не яндекс? А! маленький проект. Понял. Т.е. нагрузок-то не много, и им сразу то в общем не где взяться. А когда будут нагрузки? Через пару лет? Ну тогда там и будешь думать. Больше нагрузки - больше бюджет.
Как поймёшь свои нужды, поймёшь что тебе пытаются втюхать, поймёшь, что брать, а что лишено смысла. Дальше читать документацию, много и вдумчиво читать. Можно прямо завернуть и курить. Но, всё равно читать. Теперь, когда ты освоился с теорией, заглянуть в план и состыковаться с ним. И делать.
P.S.: много думать вредно.

Начало. Мои мысли.

Первое, о чем хочется поговорить, это о том, кто такой системный администратор.
Вот обобщенное определение(годное для soho) из вики:

Системный администратор (англ. system administrator) — сотрудник, должностные обязанности которого подразумевают обеспечение штатной работы парка компьютерной техники, сети и программного обеспечения, а также обеспечение информационной безопасности в организации.

Ну пусть будет так, естественно есть большой набор специализаций и об этом надо помнить.
Ладно. Но обычный человек это не понимает. Обычно даже не разделяет понятия программист и сисадмин. Хотя предмет один, а области разные.
Давайте с начала, так сказать к генетической цепочке
В начале был чайник, ну чайник включил кнопку питания и стал начинающим пользователем, начинающий пользователь освоил мышь и понял, что компьютер похож на печатную машинку, только круче - она с колонками, а ещё в нем есть телек. Подключившись к сети, новичок стал пользователем. И пользователь понял, что компьютеру можно найти массу применений, это же универсальный помощник. Замусорив машину и словив пару троянов, попутно угрохав ось, наш пользователь стал продвинутым пользователем. И вот тут он задает себе вопрос, как же вся эта компьютерная магия работает. Разбираясь и настраивая, магия начинает уходить, и наш продвинутый пользователь становится админом. По мере избавления от магии, он станет системным инженером. Но это после.
В общем уровни я описал. Где конкретно ты, не мне решать, что радует.
А чего из этого количества букв следует? А то, что надо избавляться от магии. Каким способом? Это не ко мне, но способов этих много.

Заметки сисьадмина (Предисловие)

Давно хотел в не очень сжатом виде начать описывать весь процесс сисадминства. Сразу оговорюсь, я не читал сотню трудов ученых и маркетолог на тему "Что такое системное администрирование?". Я занимался практикой. Вот её я и намерен изложить.
Пожалуй, что тут я изложу(в начале буду наполнять) список того, о чем я хочу рассказать:
0. Начало. Мои мысли.
1. Первые шаги.

Прекрасный символ Олимпиады в Сочи 2014

P.S.: Автор не известен, но я очень признателен ему.