Часть 4. Storage. Где?

Storage {
Name = storage-sd
#Do not use "localhost" here  
Address = gate.init-ltd.ru              
SDPort = 9103
Password = "storage_passwd"
Device = FileStorage # in bacula-sd section Device.Name
Media Type = File
}

Секции с описанием как подцепляться к хранилищу. Соответственно клиент хранилища описывается в /etc/bacula/bacula-sd.conf на том хосте, где у вас хранилище будет.

Name - название, которое будет фигурировать в других секциях.

Address/Port - по какому адресу и порту стучаться к клиенту.

Password - пароль, должен совпадать с паролем на storage клиенте.

Device  - Дублируется с секцией в на storage клиенте. От этого зависит поведение резерва.

Media Type -  Описывает, что за устройство я хочу использовать. Вариантов тут достаточно, что бы оценить гибкость бакулы. Дублируется с секцией в на storage клиенте. Некоторые варианты:

• File
• DVD
• 8mm

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

Bacula. Часть 2. Jobs

Что же, продолжу я свой сказ.

На главном месте у бакулы это задания. Эта секция называется "Jobs".

Job {
    Name = "ns-backup"
    Type = Backup
    Level = Incremental
    Client = ns-fd
    FileSet = "ns.example.com"
    Storage = "storage1-sd"
    Pool = "Default"
    Messages = Standard
    Schedule = "WeeklyCycle"
    Write Bootstrap = "/var/lib/bacula/ns.bsr"
    Priority = 10
}

Это как пример, и да, это практически боевой конфиг, названия только другие, более понятные для меня.

Параметр "Name" пригодится нам, что бы идентифицировать это задание.

Совет: названия давайте нормальные, которые реально идентифицируют объект.
Пример: msk.kremlin.dc.5.rack.15, server1.example.com.
Плохой пример: object1, comp2, comp3.

Type -  надо знать два типа Backup и Restore. Не поверишь, но это именно то, чем занимается данное задание.

Level - это уровень бэкапа. Надо знать и понимать три типа: инкрементальный, дифференциальный, полный. Опишу их:

Полный - делаем полную резервную копию. Что бы восстановить данные нужна именно она.


Инкрементальный - делаем сначала полную копию, затем только изменение с предыдущего резерва. Учти, что когда будет восстановление данных, то инкрементальные бэкапы будут накладывать друг на друга. Восстановление может длиться достаточно долго. Интересно использовать данный тип, когда данные добавляются малыми порциями и линейно.


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

Client - значение берется из секции Client и говорит, на какой клиентской машине будет производится резервирование.

Fileset - список данных, которые необходимо забирать для резерва. Значение из секции FileSet.
Естественно, что список данных может быть один и тот же для разных клиентов. А может быть и разным.

Storage - на какое хранилище будет отправлена резервная копия. Название берем из секции Storage.

Pool - в какую очередь попадает наше задание. Очередь достаточно занятное понятие, которого в простеньких системах даже нет. Значение берем из секции Pool

Message - куда писать сообщения и статусы о задании. Эту секцию можно увидеть в первой части.

Schedule - график выполнения заданий, т.е. в какое время надо выполнять задание. Значение берется из секции Schedule.

JobDefs - секция, которая тут нет, но она достаточно важна. Если есть параметры, которые у вас для многих заданий идентичны, то их можно выделить в секции JobDefs и дать им имя и использовать их уже в короткой нотации.

Вывод: для описания задания требуется только знать название в секции. Это дает лаконичное представление о задании. Важно лаконично называть секции, что бы вам сразу становилось понятно что, где и когда.

Bacula. Часть первая.

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

1. Управление
2. Клиенты
3.  Хранилища

Начну с хранилища.
За работу с хранилищами отвечает сервис bacula-sd. Зачем отдельный сервис? Дело в том, что хранилища бывают разными: на хардах, на лентах, на оптических дисках, да хоть на флешках. А бывают ещё и библиотеки для лент и оптики. Вот ко всему этому добру данный сервис и дает вам доступ. Причем эти сервисы могут быть раскинуты по разным физическим машинам, что позволяет  делать хоть гео-распределенное хранилище. За сервисами хранилищ следит сервис управления, через единый интерфейс взаимодействия. Вот и получается, что можно заготовить такие схемы хранения, что хватит практически на любого изысканного гурмана. 

Сервис клиентов.
Собственно сервис, по средством которого будет осуществлено резервирование данных. Вы просто устанавливаете клиент и задаете ему пароль. На клиенте не надо указывать, что и когда вы хотите делать. Все ваши действия вы будете указывать на стороне управляющего сервиса, кроме отдельных специфичных скриптов. Сами понимаете, что скрипты под windows в linux среде отлаживать немного ... неудобно. А клиентские сервисы имеются под множество платформ. Т.е. на стороне клиента надо делать минимум действий. Удобно администратору с гигантским парком машин - минимум возни с клиентской частью.

Сервис управления.
Воистину монстр. Базовый конфиг занимает около 300 строк. Реальный ужас, а после пару клиентов и сложных комбинаций заданий, вообще способен быстро вырасти свыше 1000 строк. Т.ч. первое действие, которое надо сделать, это разбить по отдельным файлам разделы из файла bacula-dir.conf. В конфиге bacula подгрузка данных делается через директиву @/path/to/file.name.
Как сделал я? Я разделил конфиги на следущие секции:

• jobs,
• clients,
• filesets,
• pools,
• schedulers,
• storages

 И вынес соответствующие секции из bacula-dir.conf в отдельные файлы и прописал им пути в основном конфиге. В итоге остались несколько секций в основном конфиге.
Да собственно теперь можно сразу вынести листинг

Director {                        
    Name = backup-dir
    DIRport = 9101                
    QueryFile = "/etc/bacula/scripts/query.sql"
    WorkingDirectory = "/var/lib/bacula"
    PidDirectory = "/var/run/bacula"
    Maximum Concurrent Jobs = 1 # можно запускать только одно задание
    Password = "my_director pass"         # Console password
    Messages = Daemon
    DirAddresses = { 
        ip = {  addr = some.localnetwork;
                port = 9101;
        }
        ip = {  addr = some.internet.host;
                port = 9101;
        }
        ip = {
                addr = 127.0.0.1;
                port = 9101;
        } 
    } # Сделано так, потому как есть ещё пару сетевых интерфейсов куда светить не надо
}

Catalog {
    Name = BackupCatalog
    dbname = "bacula";# dbuser = "bacula"; dbpassword = "" нету так как sqlite
}

# Консоль - это четвертая часть в бакуле, но так как настройки большой не требует
# то я её и не описывал. Единственное, что в конфиге консоли пароль должен совпадать

Console {
    Name = backup-mon
    Password = "my_console_pass"         # Console password
    CommandACL = status, .status
}
# Здесь системные сообщения. В общем это отдельная песня. Пока лучше оставить так, как есть
Messages {
    Name = Standard
    mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: %t %e of %c %l\" %r"
    operatorcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: Intervention needed for %j\" %r"
    mail = root@localhost = all, !skipped            
    operator = root@localhost = mount
    catalog = all
    console = all, !skipped, !saved
    append = "/var/lib/bacula/log" = all, !skipped
}


Messages {
    Name = Daemon
    mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula daemon message\" %r"
    mail = root@localhost = all, !skipped            
    console = all, !skipped, !saved
    append = "/var/lib/bacula/log" = all, !skipped
}

# Импортирование конфига для различных секций
@/etc/bacula/bacula-dir-jobdefs.conf
@/etc/bacula/bacula-dir-job.conf
@/etc/bacula/bacula-dir-fileset.conf
@/etc/bacula/bacula-dir-schedule.conf
@/etc/bacula/bacula-dir-client.conf
@/etc/bacula/bacula-dir-storage.conf
@/etc/bacula/bacula-dir-pool.conf

В следующей части я объясню как работает связка.

svn миграция директории в другой проект

Вот понадобилось мне со всей историей мигрировать часть проекта из одного svn проекта в другой.
Копируем весь проект

svnadmin dump /path/to/prev_svn > prev_svn.dump

Теперь фильтруем то, что нам надо забрать

svndumpfilter include path/to/dir --drop-empty-revs --renumber-revs --preserve-revprops < prev_svn.dump > dir_only.dump

А дальше, подгружаем проект

svnadmin load /path/to/new_svn < dir_only.dump

Ну вся эта комбинация займет где-то минуту.

Размер табов в nano

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

nano -T 4 /path/to/some.file

Для того, что бы задать размер постоянно, надо раскомментировать в /etc/nanorc параметр set tabsize и задать удобное значение.

P.S.: мне tabsize удобен шириной в 4 пробела.
  

Умер Стив Джобс

Умер очень остроумный и приятный человек. Отец-основатель компании Яббл. Для меня это очень сильная новость. Пойдемте поминать дамы и господа.

Помогу, чем смогу. Я знаю, что это за яма, знаю как туда попасть, и знаю как сложно оттуда выбраться. Это реально сложно.
По этому желаю всяческих благ, да и вам советую. Увидели, вытаскивайте. Промедление тут - смерть.

Аппаратный или софтварный райд? SSD или SAS? Что же лучше?

Первый же вопрос: "Почему не гибридный? Или используй тот, что в матери!" Сразу скажу, что это липовый райд. Харды будут так же видны. Разница между аппаратным и софтварным райдом сейчас уже практически стирается. Почему? Всё просто. Когда у вас один проц с одним ядром, то его ресурсы - драгоценность. Когда у вас два проца с 4-8 ядрами, то ядро на райд - нет проблем. Даже если супер АРМ ядро будет точено под raid5 или raid6, оно всё равно не будет обгонять на порядки одно или два х86 ядра. Вот и вся история. Для одноядерных или двуядерных процов, это ещё может быть подспорьем, дальше проца уже хватает.
Так же, не стоит забывать, что внутри аппаратных райдов сейчас зачастую стоит что-то похожее на mdadm.

Совсем недавно проверял, можно ли подцепить данные с аппаратного sata райда(adaptec), без самого райда. В общем там был mdadm. Я не был удивлён.

Вообще аппаратные raid контроллеры хороши тогда, когда надо выдавить максимум по IOPS или по линейной скорости на большом количестве потоков. И то, стоит помнить, что этот максимум будет прилично различаться между SOFT & HARD когда жестянок будет много.

Теперь я поговорю за SSD. Без условий считаю, что ближайшие 5 лет рынок SAS HDD в серверном сегменте начнёт отмирать. Почему? Для скорости есть SSD, а для плотности есть SATA HDD. Т.к. SAS HDD не стоят по середине по параметрам, а по цене очень даже близки к SSD, то они проигрывают.

Хоть SSD пока и отваливается на высоких нагрузках, но я более чем уверен, что если SSD смогут продержаться хотя бы год в высоко нагруженном сегменте, то их можно и нужно использовать. Резервирование и грамотное планирование отказов SSD поможет им.
Так же стоит помнить, что уже сейчас многие новые SSD близки к потолку в 600MBps. И количество IOPS по записи превышает 20kIOps. Ни один из известных мне raid0 массивов на 8 SAS HDD даже близко не показывает подобные результаты. По линейной скорости ещё может быть и обгонит, а вот по IOps - не судьба. Стоимость же SSD, даже с учетом серверной ориентированности, 1Гб - 150 руб (думаю, что дойдет до 50 руб), а 8 SAS 300Гб c учетом контроллера от 70 до 120 т.р., что на гиг будут от 250 до 400 руб. Конечно SAS проживет под нагрузкой 5 лет, а то и более, но вот высоким скоростям там в ближайшие 10 лет взяться не откуда. А вот SSD есть чем расти для увеличения срока службы. В общем думайте сами, решайте сами.

Моё же личное мнение таково:
Сейчас есть смысл брать SSD и в серверный сегмент, но только SSD с кешем, коллектором мусора и TRIM.

За охлаждение поднимем бокалы.

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

Сразу замечу, что практически всегда тепло мы скидываем в атмосферу, но и в воду тоже можно его сбрасывать.

Так что там касательно серверных?
А с серверными всё обычно просто. Мы подаем в передние вентиляционные отверстия (через дверь) "холодный" воздух, на выходе у нас "горячий". Дальше кондиционер забирает тепло с "горячего" воздуха и он снова становится "холодным". А тепло от кондиционера отдается в атмосферу.

Вот собственно вся система. Теперь я поговорю о том, почему это сложно и что-же тут сложного.

К смотрящим.

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

Серверная - больше не значит лучше.

Много - это хорошо! Больше - лучше!
Все мы поклонники таких тезисов, но вот так ли это на самом деле? Природа, да и банальный житейский опыт показывает, что не так. Много, не значит лучше.

Вот и в серверной много проводов это не значит хорошо. Вот два примера:

Хоть и разные виды, но какой из них лучше?

Серверная - моя прееелеееесть.

Каждый сис. админ так или иначе имеет в своём попечении что-то вроде серверной.
У кого-то это комнатушка, у кого тумба с парой компов, у кого ДЦ. Размер не главное, а главное, что это нас всех объединяет. Ни один сис. админ, на моей памяти не ругнётся "что это у тебя за кроха", а скажет "О прикольно, а что тут? Да как это работает?"

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

В общем зачем сейчас много компьютеров в фирмах? Это вопрос не праздный и от ответа на него будет зависеть наша серверная. В легком случае можно взять прегородки из двухкамерных стекол , обнести стойку и сделать дверь. Или же в отдельном помещении организовать стеллаж и ставить сервера туда. Когда серверов не много, то это даст приемлемый результат.

Но почему же требуется столько серверов?
Ответ как всегда в истории. Так сложилось, что ещё 10 лет назад 2 ядерные процы x86 были из области ноу-хау. Двухпроцессорные системы были, а вот двухядерных нет. А в серверных системах, что тогда, что сейчас можно запросто встретить компы, в которых активных процессов сейчас крутится с десяток. Под каждый можно было выделить свой хард, но вот процессор выделить было нельзя. Как сейчас помню тот гордый p2 400 который тянул сеть на 20 машин, раздавал шару, инет, трудягу осла тянул и почту ещё на себе. Всё это он делал ... плохо. Его попросту переставало хватать, хардом трещал так, как у стоматолога особо пугливые не выстукивают. Пришлось тогда заводить еще 2 машинки, под почту и осла. Вот вам уже 3 сервера. Потом штат компов разрастался и наступила пора доменов и пары БД. Конечно сервера брали мощнее, и вот в 2006 году обзавелись двухядерными. А под БД, были гордые красавцы двухпроцессорники(2 шт.).  И с тех пор, особенно ничего нового в серверной не делали. Правда ещё комп под  апач закинули. Вот вам и стойка из 4U корпусов, кондишн работающий на полную и минимальный выхлоп. Всё это я сейчас заменю на два  6 ядерника, а в каждом по паре SSD и паре SATA. Получится круче, дешевле по питанию и проще в охлаждении. И в бюджет 50 штук я со скрипом влезу.
А электричество сжирает первый вариант, так вообще. И поверьте мне, за год сумма набегает приличная. Это же как никак 3-4 кВт в час круглосуточно, и полный год. А это если по 5 руб за кВт, получается в 131 000 (3 кВт) рубликов в год, а если  400 Вт, то 17500 рубликов в год. Разница в две машинки только за год. Вот вам и вся экономика. И ответ на вопрос, почему сервера обновлять стоит.

Так же не стоит забывать, и про сеть. Новые железки, новые скорости. Дешевле порты.
А ещё, чем меньше в серверной проводов тем лучше. Этот тезис я поясню позже.

Да и с охлаждением сейчас вообще повсеместно беда.
   

ssh и vpn

Есть такая отвратительная, глючная и тупая штука, как VPN. Делает она следующее, как бы устраивает туннель между двумя сетями, причем так, что бы другие в него не ломились.

Вообще эта технология называет tunneling и известна достаточно давно. Сегодня расскажу по такую замечательную вещь, как ssh.
- Стоп, ты о ней уже говорил!
- Говорил, но не о всем же вкусном в нем.

В общем есть у ssh ключик, который позволяет в рамках ssh сессии прокинуть туннель.
Что мы будем иметь в сухом остатке:

• Безопасность, т.к. всё шифруется.
• Удобство.
• Авто вход.

Ковыряю ajenti под lenny

Собственно веб админка. Кто-то будет кричать: "Долой админки, да прибудет с нами ssh". Ну и пусть кричат, а мне иногда хочется иметь всё в одном месте и удобно. И ничего кроме веб-админки ставить не желаю. Знаю, что для автоматизации процесса на ентерпрайзах используют всякий доп. софт. Но это не наш метод.

В общем почему ajenti? Красивая ajax админка. Правда по плагинам до уровня webmin еще расти и расти. Но webmin'овский интерфейс - убогий. Вот ну честно. Это жестокий фарш из тонны опций.

Устанавливается просто в /etc/apt/source.list сначала всё lenny заменил на squeeze и добавил
UPD: Сее действо уже устарело

deb http://repo.ajenti.org/debian /

Надо так
deb http://repo.ajenti.org/debian main main


А дальше в консоль за ключами

wget http://repo.ajenti.org/debian/key -O- | apt-key add -

Собственно aptitude update && aptitude install ajenti

Ну и не забываем на lenny откатить в списке зеркал(/etc/apt/source.list).

Из минусов. Не спросил пароль при установке. Я ожидаю такие вещи при установки в консоле. Да, после ввода admin/admin предлагает сразу сменить связку, но это идеологически не верно. Ну и cron пока в cron.d не смотрит, а только crontab -e. В остальном желаю проекту дальше развиваться.

P.S.: для python девелоперов ajenti самое то :)
P.P.S.: вот думаю над интерфейсом к бинду. Пока играюсь с ajenti.

Короткий и полный урл при разработке.

Сам,  в свое время использовал полные урлы везде и всегда, но это очень плохо, почему? Ну спросите об этом создателей клиент-банка для малого бизнеса в Сбербанке. При обращению в хелп, я получил следующий линк http://localhost:8080/ic/help/html/index.html?
Понятно, что в ответ вы получите хрен, либо ексепшен(исключение), т.к. на этом порту у меня вертится локальный вебсервер и ничего о таком адресе он не слышал.

Правило первое, когда вы пишите что-то на стороне сервера никогда свой урл не описывайте полностью. Почему? А вдруг переезд на другой домен и всё упало :) Вот будет радости-то.
T.e. href="http://example.com/page/1/" Лучше нигде не писать,  надо сделать так href="/page/1/"
Вот если example.com это внешний сервис, и там нужная инфа (картинка к примеру), то да полный путь заказан.
Второе, и что тоже не менее важно. К примеру у джанги для шаблонов есть такой тег {% url %}
В файле с описанием урлов, каждому шаблону урлов можно задать name.
И если шаблону ^/page/\d+/$, name="page", то получим href="{% url page 1 %}"
Тогда как-бы в последствии мы не меняли внутреннее название страниц, на сайте проблем мы не увидим.

В помощь начинающему программисту.

Ну что там обычно новичку советуют? Типа изучай си, нет си сложен, изучай паскаль... посмотри на php. О есть такая штука как питон. Нет, об этом я сегодня говорить не буду. И не буду сравнивать, ide и "блокнот". Сегодня я расскажу о важном и удобном инструменте

В общем ситуация с кодом такая, что если ты ценишь свой труд, то ты захочешь сохранить свой код. Тут спасают бэкапы  - это понятно. А что делать с кодом, когда с ним работают несколько человек? А что делать, если надо вести сразу несколько вариантов проекта? А как организовать совместную работу над проектом? Вот на эти вопросы многие ответа и не знают. Ну конечно можно обговорить все последовательности действий. Разработать четкую структура, кто в какой код лезет, но это обычно сложно и не очень продуктивно. Ну сами посудите, я пишу кусок кода, тут оказывается, что в Васином участке какой-то глюк, поправить я его не могу, только отослать Васе, Вася ругается, что правил Федя и он дурак. И не понятно в итоге, что толком делать. 

Новичкам. Как упрощать себе админство или зачем нам мониторинг.

Побьют меня за мой язык, но скажу следующий тезис. Системный администратор - это высококвалифицированная(ый) уборщица(к). Т.е. это та должность которая непосредственно не влияет на функционирование проекта. К чему я это? А к тому, что на вверенной тебе территории ты должен знать что происходит, и уделять при этом как можно меньше сил. Это от того, что сделаешь ли ты на 5+ или  на 3-, никто в компании об этом не узнает, до момента когда всё не рухнет(т.е. станет совсем грязно - прим. уборщицы(ка)). Т.е. непосредственный твой начальник - это возглас работников "шо за нах(WTF)". Т.е. следить за всем приходится всегда тебе.
А что мы знаем о средствах слежения. Бинокль, радио метки, радарные комплексы... не чего-то они мне ни как не помогают. Следим мы по статусу WTF(см. выше). Т.к. 24 часа в сутки мониторить серваки не возможно, то кто-то это должен делать за тебя. Можно нанать пару китайцев или индусов (да именно так работают в крупных компаниях), но у нас бюджет. Да и время реакции в 15-30 минут не критично.

весть о lvm и snapshots

Часто делая бэкап я ловил себя на мысли: "Статику бэкапить одно удовольствие, а динамику - долго и беда". Ну правда, статический контент он по определению не очень меняется. А вот динамический стремится в любую секунду меняться по десятку, а то и сотне раз. И беда в том, что это как правило БД или почтовые ящики пользаков. И останавливать сервис на долго нельзя. Ну т.е. если на 3-4 минуты, нас с тобой никто не убьет (ну в общем всё зависит от того, чем занимаемся, на фондовой бирже так делать не стоит), а вот если на час или два ... в общем без комментариев.

Статику мы можем копировать, а вот с динамикой ... останови БД, скопируй, запусти. Вот как раз процесс копирования может быть очень долог. Что делать?

Ограничение работы за компьютером детей под debian

Собственно задача проста. Есть дети, есть компьютер, но нет взрослого. Понятно дело, что хочется обезопасить детей от "злого интернета", но эта тема отдельного разговора. Но бывает так, и очень часто, что дети засиживаются за компьютером, да не один час, а 5-6 часов.
А хочется не больше пару часов, пусть хоть и играет, но ограниченное время.

Как просмотреть раздел внутри раздела или kpartx в деле

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

Вот собственно с помощью чего это можно посмотреть
apt-get install kpartx

допустим /dev/sata-vol/virt1-root корневой раздел нашей виртуальной машины. На нем какие-то свои разделы.

kpartx -l /dev/sata-vol/virt1-root # покажет как будут связаны эти разделы с текущим /dev
kpartx -a /dev/sata-vol/virt1-root # свяжет эти разделы, и они станут доступны

P.S.: вот таким простым и не хитрым способом мы увидим внутренности нашего раздела.

debian и lvm

С начала ещё раз о разделах.

В чем их основной минус? В том, что размер раздела больше емкости одной хардянки сделать не получится. Помогает только райд или ... lvm.

Есть второй косяк за разделами, не возможность online(на лету) расширения раздела, если нет свободного места перед следующим разделом. Ну к примеру.

sda1 - 10 Гигов

свободно 20 Гигов

sda2 - 40 гигов

sda3 - 60 гигов

свободно 50 Гигов

В данном случае, по быстрому sda1 увеличить можно только на 20 Гигов, sda3 на 50 Гигов, а sda2 в обломе. Т.е. если понадобится больше место для sda2, то придется двигать разделы. Эта операция явно не на 10 минут и сервер будет в простое. Т.е. приятных тебе выходных. А ты как думаешь, в рабочее время что ли?

Вот по этому-то с разделами такая давняя вражда у многих. И со вторым косяком тебе ни какой райд не поможет.

Как разбивать диски или что я делал не так.

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

Что я люблю использовать в этом деле.
1. Это LVM, о нем я расскажу чуток позже, но штука крайне полезная, особенно когда надо расширять дисковое пространство.
2. Мозг. Да бывало не использовал.

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

Что хорошего в этих подходах.
В первом - не заморачиваемся. Один раздел подо всё. Но с другой стороны в случае каких-либо ошибок на разделе приготовьтесь, что ждать проверки при 2-4 Тб, вам придется очень долго. И  бэкап целого раздела, в таком случае, это что-то с чем-то.

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

Что лучше? В общем ситуация тут такая. Когда места много и система стабильна разницы то и нет. Но, когда мы подходим к лимиту места, вот тут-то и появляется разница.
Ну например. У нас такая схема. Перечисляю каталоги у которых отдельные разделы(partitions)
/var/www # каталог для веба
/var/db # каталог для БД
/var/mail # каталог для почты
/var/log  # каталог логов
/ # корневой каталог

Например мы взяли и что-нибудь скачали в /root и практически под завязку забили корневой раздел(так делать не стоит, но иногда бывает, бэкап пишется в сеть, а сетевая шара смонтированная в раздел /root/backups отпала, вот и пишет он в корень). В случае если у нас один раздел на всё, то у нас скорее всего быстро отпадут логи, откажет БД на запись, и веб-сервер перестанет нормально функционировать, а также почта упадет. Т.е. сервер получил авто-dos(denial of service). Что не очень приятно. А вообще даже и катастрофично может быть. В случае когда под эти сервисы будут выделены отдельные разделы, то забивание корневого раздела это не беда.
Важно то, что если раздел сервиса почты вдруг переполнится, то БД не упадет и веб будет жить. Т.ч. в серверном варианте я за этот метод.

А по скольку каждому отдавать? Тут всё зависит от вас. И не читайте best-practice, где кто-то говорит 5.43Гига хватит под этот каталог, это бред, т.к. человек не знает вашей задачи. И ... беда, в начале вопрос сколько места и куда решить практически не возможно. В этом и вся загвоздка для начинающих. Место нужно сказать сейчас, а конкретно как оно будет на самом деле, хрен его знает. По этому часто и выбирают всё на одном разделе.

Вот например есть у меня самба, с хранением профилей подоконных пользователей.
В начале я выдал на профили 40 Гб, на шару 60Гб. И уже через 2 года места для профилей не осталось. И это при 10 пользователях. На самом деле всё место сожрали только 3 пользователя. А думал, что места хватит на 5 лет :) (Оптимист хренов). Спустя шесть лет(в сумме 8 лет) могу сказать, что профили пользователей весят в сумме 80Гиг, шара и хомяки (жарг. - домашние папки) весят 80Гиг. Вот такая беда. А раздел в начале был один на всех - 100 Гиг (Хардянки были по 120 Гигов в RAID1).

Так как же побороть страх перед множеством разделов? Вот об этом в следующем посте про LVM, тут он нам будет другом.

Бэкап. От слов к делу прошу любить и жаловать backup-manager

В общем ситуация такая. Бэкап может быть комплексным, а может быть и простым.
Есть много всяких программ для бэкапа. Есть платные, есть бесплатные. Смотреть мы будем в сторону бесплатных. Есть такая вещь как bacula, она сложная, но очень гибкая. О ней как-нибудь позже. А сейчас представлю тебе виновника этого поста backup-manager.
Устанавливаем:
apt-get install backup-manager
Он задаст пару вопросов и в общем ответив на них бэкап заработает.
Я правда всё равно потом правил немного конфигурационный файл.

Есть правда одно но, перед тем как устанавливать найди место для размещения бэкапа, т.к. он этот бэкап после установки сразу начнет делать.

backup-manager умеет работать с mysql, умеет дампить subversion, естественно работать с файлами, а так же с pipe. Ну и делать полные  и инкрементальные бэкапы. А также кидать всё это дело на amazon S3 или по ssh куда-нибудь, немного с rsync умеет работать.

У меня на сервере как раз subversion, www, mysql.

Вот пример настроек которые я изменил в файле /etc/basckup-manager.conf

# Где хранить бэкап
export BM_REPOSITORY_ROOT="/root/backup" # правда это сетевая шара.

# кто владелец файлов

export BM_REPOSITORY_USER="root"

export BM_REPOSITORY_GROUP="root"

# какие типы архивов надо будет делать, какие укажешь в ту секцию затем и лезь писать 

# настройки, за исключением tarball-incremental, т.к. он использует значения из tarball

export BM_ARCHIVE_METHOD="tarball-incremental mysql svn"

# Какие директории сохранять, etc - оно понятно. Не ленитесь сохранять конфиги.
# Хотя так же не ленитесь их записывать где-нибудь в инете.
# /var/www - директория с веб-проектами.
# /srv/trac - директория с trac проектами, хоть они и веб, но я вынес их отдельно
export BM_TARBALL_DIRECTORIES="/etc /var/www /srv/trac"

# промежуток между полными бэкапами.
export BM_TARBALLINC_MASTERDATETYPE="weekly"


# какие БД дампить, через пробел или все как у меня. Тут, что вам нужнее.
export BM_MYSQL_DATABASES="__ALL__"

# логин и пароль на доступ к БД

export BM_MYSQL_ADMINLOGIN="root"

export BM_MYSQL_ADMINPASS="password" # пароль я естественно поменял.

# Тут касательно svn репозитариев. Через пробел  

export BM_SVN_REPOSITORIES="/srv/svn/repo1 /srv/svn/repo2 /srv/svn/repo3"

Бэкап и как его есть.

Много чего я слышал про бэкап, и сам в молодости много чего не правильного про это дело говорил.
А давай подумаем что такое резервирование данных (в простонародье бэкап). В самом понятии всё заложено, это процедура создания и хранения запасной и в достаточной степени актуальной информации.
Т.е. если информация не актуальна через год, то смысла хранить нам эту информацию нет.
Если информация вообще не актуальна, то и хранить её нет смысла. Ну к примеру, у вас есть софт (к примеру firefox v2.1) и доступ к месту где всегда можно скачать нужную версию софта (ну торрент к примеру), то зачем вам в бэкап этот софт? Через какой-то промежуток времени, этот софт будет не актуален, а достать его будет легко. Т.е. нам с тобой нет нужды хранить хорошо доступную информацию.
Т.е. храним только то, что нужно и что нельзя найти из вне. И складируем эту информацию согласно актуальности.
Актуальность информации вещь сложная. Вот пример из моей рутины:
Есть небольшая база бухгалтерии. Средняя такая фирмочка.
Заранее известно, что месячный объем данных вбивается за неделю (такое часто бывает даже в средних фирмах). Т.е. если мы профукаем месячные данные, то у нас вычтут ЗП бухгалтера за 2 недели. Что не мало в принципе. Если профукаем недельные данные, то взбучку и премия долой. Если данные за 1-2 дня, то коробка вина и бутылка конфет - наше спасение. Т.е. необходимый срок резервирования - 1 или 2 дня. Так же стоит помнить, что у бухов красный месяц календаря бывает 4 раза в году (точнее 4.5). Т.е. в определенное время нам просто необходимо иметь резерв квартальных данных. Если что случится и не будет данных, то в задний проход швабру без вазелина - считай, что просто повезло и молись за такое везение.
А к чему я это все? Да к тому, что график и количество резервирования данных надо планировать для любой информации, и планирования это спасет от перерасхода места . А принцип "места много - влезет", отпадает по двум причинам:
1. Места всегда мало # я вот сейчас даже подумать боюсь, как я жил на 40Mb(я не ошибся именно сорок метров) винте.
2. Бэкап имеет место разрастаться со временем. # я тут новость не открыл
3. Принцип разумной достаточности никто не отменял # можно для маленькой фирмы и библиотеку ленточную купить, только вот дорого и не нужно.

Если в голове ещё стоит вопрос "А нафига оно мне надо", то вспомни про швабру без вазелина  и, представь, как она тебя ожидает. А я, пока ты будешь в ужасе изгонять швабру из своего мозга, расскажу тебе реальную историю:
    Некто П. обратился ко мне с "не работает ноут, я тут винду переставил, а данных нет. Верни, а то там фото и видео моего ребенка, жена мне яйца отрежет!" Причем по его виду я уже понял, что не шутит, и по мозгу она ему уже хорошо шлиф-машинкой прошлась. Данные я восстановил и его это спасло. Дал ему дельный совет, что и как делать. Через пол-года он снова обратился ко мне, только случай был хуже. А бэкапов он не делал. Что стало с его мозгом и с ним самим, я умолчу. Но поверь мне, я бы этого врагу своему не пожелал.

Дальше нам бы посмотреть, что нужно для бэкапа. А для него самое важное - место.

Надо понимать, что копию какой-нибудь одной вещи надо держать несколько. В разных временных рамках и прочее. Почему так, а многое, что может произойти. К примеру умышленный долгосрочный саботаж. Резкое изменения структуры данных. Систематические ошибки при обновлении ПО Т.е. мы попросту с тобой можем быть не готовы при одной единственной актуальной копии. Вот тут-то нас райды всякие и не спасают. Потому как это не резервное хранение данных. Ну а раз копий может быть несколько - к примеру 5 штук полных копий, то и данных будет в 5 раз больше. Значит места нужно не мало.

А теперь о железяках всяких.
Часто люди считают, что рейд спасет отца "русской демократии". Но не стоит забывать, что эта технология призвана сохранять работоспособность системы в случае смерти одного или нескольких хардов, но ни как не защищает нам от порчи информации посредством шаловливых ручек. А что есть на рынке, а на рынке в общем есть два варианта:
Ленты или харды. Другого в общем и нет.
У каждого варианта свои плюсы и минусы:
Ленты - физически и химически достаточно устойчивы (+). Цена достаточно дороговата, линейная запись и чтение (т.е. если надо обратить в середину данных, то прокрутить придется до середины) (-). Использовать кроме как в бэкапе сложно (-). Нужно спец. оборудование - стример (магнитофон :) ), иногда библиотека. Библиотека - это штука которая может менять кассеты в стримере и складировать в необходимом порядке кассеты(-). Оборудование не из дешевых и если объемы у нас маленькие, то не для нас (-). Ленты можно считывать на оборудовании других компаний, лишь бы стандарт подходил (+). Долгий срок хранения (+)
Харды - хранилище с хардами, простые харды. Можно взять салазки и записывать всё как на ленту. Записал на хард, вытащил старый, вставил новый. Унес старый и поехало по новой.
Плюс хардов - большая емкость, чем у ленты за туже стоимость (+). Нет необходимости в спец. оборудовании(+). Можно использовать не только для бэкапа(ну вот не хватает 500Gb харада, купил на  2 Тэра, 500 гиговый можно пристроить) (+). Не устойчив к физическим воздействиям, падения или окунуть в лужу. Если сгорит управляющая плата, то сложно с её заменой (-). Гарантийный срок годности, т.е. положить на 15 лет хард на полку не очень получится  (-).

Есть правда третий способ, о нем в следующей статье.

Важно ещё понимать, что бэкап условно хорошо хранить по дальше от места основных данных. Да, именно под дальше. Лучше, на другом краю света. Ещё лучше в трех различных точках нашей планеты. На Японию сейчас посмотрите и всё поймете. Если хранить в соседней комнате, то при таких катаклизмах с данными у вас проблема. И проблема именно в том, что только данные вам не удастся восстановить быстро и это факт. Т.к. информация это многодневный плод профессиональной работы людей. И это важно помнить.

И надо помнить, что хранить данные надо начинать уже с момента настройки системы.

P.S.: когда случится твой epic fail, ты меня поймешь. В не зависимости, есть ли у тебя бэкап или нет, только твой зад кажет кто ты на самом деле.

Удаленная работа

Важно помнить одно правило, что сис. админу надо уметь работать удаленно.
При работе с удаленными объектами надо задумываться о следующем:
1. Управление должно осуществляться по безопасным каналам связи.
2. Управление должно быть даже при очень плохом канале.

Первое требование оно простое. Я не доверяю каналу связи и хочу иметь возможность управлять сервером из любой точки мира. Почему из любой? А вдруг ты на Камчатке, а я в Москве. Всяко бывает. И бывает так, что подключаешься к халявному вайфаю, а у человека там tcpdump во всю играет. Вот твой пароль от сервера уже и у него. А значит и сервер его. Т.е. хочется иметь возможность авторизовываться и сообщать команды по шифрованному соединению.

Второе требование ещё проще. Я поехал в поездку и у меня из "ентернетов этих" только gprs. Да ещё и связь на одно деление. Вот тут сразу отпадают citrix, radmin, remote desktop аки присутствую в огромном количестве в виндоузе. Понятно, что текстовые команды тут на высоте. И дублировать на несколько серверов действия - легко.

За сим хочу представить такую вещь как ssh - security shell.
Разделяется она на две части. Нет не мужскую и женскую. Клиентскую и серверную.
Работают с этой штукой так же как и в обычной консоли, правда к удаленной консоли надобно нам подключиться:

ssh icegreg@example.com
Вот пользователь icegreg запрашивает подключению к серверу по адресу example.com. И запрашивает по 22 порту. Что такое порт? Приведу аналогию:
вот звоним мы в какую-нибудь контору. номер телефона - это адрес хоста. А нам в ответ говорят наберите добавочный номер. Вот добавочный номер и будет портом. И тот кто нам ответит на другом конце - сервер. Вот такая простая аналогия.

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

Настроек и дополнительных опций у ssh целая телега.
например ssh -X icegreg@example.com firefox
Запустит команду firefox на удаленном сервере и транслирует все запросы графического сервера на локальную машину. Т.е. будем работать в firefox, только будет он серверным.

ssh -L 4899: 192.168.1.2:4899 icegreg@example.com -Nf
если example.com так же подключен к сети 192.168.1.0/24 то он пробросит через себя все данные к порту 4899 компьютера 192.168.1.2 и обращаться к этому порту можно будет на прямую из локальной машины, по адресу 127.0.0.1:4899, а -Nf не откроет нам консоль.

Вкусностей много. Например можно сделать авторизацию только по ключам, без паролей.

Но минусы как всегда есть.
Если ты поднял этот сервер у себя на внешнем сервере, то готовься, что тебя начнут брутфорсить.
Т.е. будет валить гигантское кол-во запросов на авторизацию по справочникам.
Т.е. твои пароли не должны быть легкими и стоит в любом виде запретить пользователя root. Т.к. это точно единственно известный пользователь в системе.
А так же не давать больше 3-5 попыток авторизации на сервере.

Уф сколько всего. А теперь если подумать.
Вот веб-служба работает на 80 порту по умолчанию. ДНС на 53. ftp на 21/20.
Но это популярные общественные сервисы, а наш ssh нужен только админам.
А теперь давай подумаем. Раз атака работает автоматически и по порту 22, то если мы перекинем сервис ssh на 8022 или 9022, то и автоматический сервис по обнаружению ssh уже до нас не доберётся. И не будет атак с подбором, и не надо ставить fail2ban, для бана ip-адресов.
А т.к. пользоваться будет только узкий круг, то можно сказать всем, что по умолчанию у нас 8022. И всё. Но всё таки пароль надо сделать сильным.
Для того, что бы сервер стал работать по порту 8022
надо в файле /etc/ssh/sshd_config
строку: # Port 22
заменить на: Port 8022
и перезапустить сервер
/etc/init.d/ssh restart

Вот теперь, если зайдем на наш сервер, то ssh не зайдет.
Т.к. стучится он на порт 22, а ответа там нет.
тут есть два варианта
ssh icegreg@example.com -p 8022
или же поправить порт по умолчанию в файле /etc/ssh/ssh_config
И так же указать: Port 8022

В общем таким способом наш лог-файл /var/log/auth.log перестанет разрастаться прямо на глазах.
P.S.: хотя профит в fail2ban по ssh тоже есть :) Но он уже для профи так сказать.

Поговорим о рабочих командах.

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

Хорошо помогает в деле очистки мозгов от хлама две вещи:

man <имя_команды> # будет выдана документация по команде, если таковая имеется

<имя_команды> -h # часть выводится миниатюрная помощь.

А вот собственно и сами команды:

ls  # ls <имя каталога> выводит список файлов и каталогов в указанном месте

cd # cd <имя каталога> перейдет в каталог

find # команда поиска, find <имя каталого> -name "<имя файла>"

cp # копировать файл или каталог cp /home/icegreg/1.txt cp /home/icegreg/2.txt

mv # переместить файл или каталог mv /home/icegreg/1.txt /home/icegreg/2.txt

rm # удалить файл или каталог

mkdir # создать каталог

ln # создать ссылку на объект ln -sf /home/icegreg/2.txt /home/icegreg/3.txt

chmod # редактировать права chmod 765 /home/icegreg/2.txt

chown # редактировать владельца chmod icegreg:www-data /home/icegreg/2.txt

tar # очень мощная архивная утилита

su(sudo) # стать суперпользователем

grep, awk, sed # очень мощная связка для работы с текстом.

Если посижу, то, наверное ещё буду долго вспоминать всяко разное. Но это тот базис который я "немного знаю".

   

python and virtualenv

В общем поведаю я тебе о них сегодня. Причины использования virtualenv могут быть разными, но для начала. Что такое virtualenv? Если вкратце, то это набор программ и библиотек для запуска питон-проектов в виртуальное окружении. Да, конечно можно сделать chroot. Но этот вариант много проще в разработке и поддержке.
Чем этот вариант понравился мне. Вот например есть у нас какая-нибудь библиотек, причем она в активной разработке. На базе этой библиотеки строится ряд программ. В процессе разработки часто ломается обратная совместимость, а так же зависимости от внешних библиотек. А программки, которые работают на этой библиотеки делаются не в один день и используют разные её версии. И вот тут подкрадывается тихий ужас (он же маленькая белая сибирская лисичка). Для того, что бы новая программа заработала, нужна свежая версия библиотеки, но если её поставить, то скорее всего рухнут все старые программы. Причем рефакторинг старого кода может быть очень дорогой задачей и заказчик просто не захочет этой процедуры (его право).
Ну и что, поставим на новый комп. А вот беда. Сайт - это то же программа. И так просто такую процедуру не сделаешь (ну в общем это просто, но только умеючи).
В общем тут нам на помощь приходит virtualenv
Установим:
apt-get install virtualenv
Создадим новое окружение:
virtualenv ve
У нас появится каталог, его структуру можно внимательно изучить.
можем запустить python:
ve/bin/python
А можем установить вкусности:
ve/bin/easy_install pip
ve/bin/pip install django django-any django-jenkins

Причем установить мы можем вполне конкретную версию всего по.

Так же, часто в процессе тестирование возникает желание потестить код в разных версиях python.
Вот как создать окружение с определенной версией python
virtualenv -p python2.5 ve

Так же, для удобства работы, можно активировать окружение
source ve/bin/activate
тогда уже можно просто говорить pip install <чего-то там>
Что бы выйти из окружения можно сказать exit, но лучше deactivate.

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

Структура файлов и каталогов.

Почему каталог, а не папка?

Подходящее определение каталога: "В общем случае, это некий список информации об объектах, составленный с целью облегчения поиска этих объектов по какому-то признаку"

А папка - картонное изделие. Определение "папка" в IT пришло от слова folder. Хотя на самом деле употребление folder - не правильно.

Ну это так - мои нервы. В общем, что нам надо запомнить, это то, что в линукс-системах всё является файлом или каталогом. В каком это смысле "всё"? Ну, в прямом. Практически любой объект в системе присутствует в виде чего-то похожего на файл и находится в каком-то каталоге.
Ну к примеру:
/home/icegreg/.bash_history # файл с историей введенных команд пользователя icegreg
/dev/mem # Дамп памяти
/proc/cpuinfo # информация о процессоре(ах)

И представлено всё это как файл. И стоит запомнить, что файл - это не только информация на жестком диске.
Структура каталогов в линукс-системах практически всегда общая и состоит из:
/ - корневой каталог
/bin - каталог с исполняемыми системным файлами (они же команды)
/boot - каталог с загрузочными конфигурациями
/dev - каталог с файлами устройств (не хранится на жестком диске)
/etc - каталог с конфигурационными файлами
/home - каталог с домашними папками пользователей
/lib - каталог с большинством библиотек (в основном системные библиотеки)
/mnt - служебный каталог для монтирования файловых устройств
/opt - каталог используется для установки программ, которые не входят в базовую поставку
/proc - каталог со служебной системной информацией (не хранится на жестком диске)
/sbin - каталог с исполняемыми файлами для администраторов.
/sys - каталог со служебной системной информацией (не хранится на жестком диске)
/srv - служебный каталог для сервисов. (но чаще информация хранится /var)
/usr - в этот каталог ставится большинство программ входящих в базовую поставку, тут же и документация и прочее.
/var - каталог для переменных данных, в общем все служебные данные как правило оказываются тут, например /var/www - каталог для веб-сайтов.
/tmp - каталог для временных файлов (не хранится на жестком диске)
Важно понять, что корень - "/". А так же, что вышеизложенная структура одна на всех. И что в общем нет тут ни диска С: ни D: и всё устройства - это блочный файл. И работать приходится всегда с файлом.
вот такая команда прочтет первый сата диск и отправит данные в никуда.
dd if=/dev/sda of=/dev/null

/dev/sda - первый сата(а может и сказя) диска
/dev/sda1 - первый раздел на первом сата диске
/dev/null - файл пустоты. Что туда не заверни, назад уже не вернешь.

Если в верхней команде переставить /dev/sda и /dev/null местами, то будет беда. Т.ч. осторожнее.

Как правило файлам стараются давать осмысленные имена.
Например:
/var/log/apache2/error.log
/var/www/index.html

И не надо давать название файлам в виде ab20cde.log. Это может быть понятно чьему-то больному воображению, но ни тебе, ни мне это понятно не будет. Это касается и временных файлов, потом сам рад не будешь если так назовешь когда отлаживать что-нибудь будешь.

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

На кой мне другие пользователи? Мне и пользователя 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.: Автор не известен, но я очень признателен ему.

Го и быдлокодство

В прошлом посте быдлокодства я писал про го. Но вот не задача, я создавал задания в виде №_(сила игрока текстом).sgf (если мне не изменяет память), а вот не понравилось мне. Надо конечно было "сила игрока цифрей(номер задача).sgf" Причем с конвертом цифер 0-9 в 00[0-9], ну и далее в том же духе. Но второй раз лазить за 7k задач на сервер, меня не прельстило и решил поменять, что уже спи...посмотрел на сайте.
Будет у нас 1 dan(12345).sgf. Это будет гораздо удобнее. Т.к. у нас больше 7k задач, то облегчим себе жизнь nodejs'ом
А вот и код

var fs = require('fs'),
sys = require('sys');
// Где лежат файлы
var sgf_dir = '/home/icegreg/sgf/goproblems/';
// Прочитаем директорию, список файлов в массиве files
fs.readdir(sgf_dir, function(err, files){
// Как он выглядит
var re = /(\d+)\_\((.*)\)/;
for (i=0;i<files.length;i++) {
var mt = files[i].match(re);
// Переименуем
fs.rename(sgf_dir+files[i], sgf_dir+mt[2]+'_'+mt[1]+'.sgf');
}
});

Вроде простенько и со вкусом(ну не ручками, и за 10 минут, с чайком), а польза для меня есть.
P.S.: Да, и если кому интересно го, могу помочь с освоением.

Teleport pro and linux

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

wget -m -k -nv -np ya.ru

-m зеркалирование всего и вся
-k сконвертировать ссылки на локальные файлы
-nv немного отключить срач
-np не ходить по другим ссылкам выше основного родителя ya.ru/vasja не будет качать ya.ru, ну и не будет ходить на google.com если таковой найдется. В противном случае -m будет качать до конца интернета :)

В общем спасибо пользователю sledopit, который в комментарии на хабре дал вот что:

wget -m -k -nv -np -p --user-agent=«Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)» bbc.co.uk

Всё тоже самое, только вот user-agent другой (от имени кого будет запрос). Будем гуглоботом :)

P.S.: вполне давно и с хорошим успехом так граблю инфу.
P.P.S.: и да, не поленитесь читать man wget

По быдлокодим

Собственно попался в руки nodejs.
Прикольно. Была давнишняя идея сграбить с сайта goproblems.com задачки. Собственно кто не знает, что такое Го, тому сюда
Ну а раз знакомство, то почему бы и нет. Есть два интереса с двух сторон, пожалуй можно за пару часов и разобраться. С js я немного знаком, так что проще.
Как собирать nodejs и npm, я может чуть позже расскажу. Пока всё же вещь ещё во многом сырая, на свой страх и риск, за кружечкой чего-нибудь.

var httpAgent = require('http-agent'),
jsdom = require('jsdom'),
sys = require('sys');
fs = require('fs');
// Создаем массив относительных путей
var urls = Array()
for (i=1;i<14528;i++) {urls.push('?id='+i);} // 14528 - кол-во известных номеров задач

// Алгоритм можно улучшить, а именно ходя по ссылкам "вперед" и "назад" в задачах.
// Но пусть будет в лоб, да не обидятся на меня ребята с сайта.

// Вторым параметром передаём массив относительных путей
var agent = httpAgent.create('goproblems.com/prob.php3/', urls);

agent.addListener('next', function (e, agent_res) {
// Создаём DOM-дерево из текста страницы
// Если тут ругается, то смотреть на установку libxmljs
var window = jsdom.jsdom(agent_res.body).createWindow();
// Здесь мы подключаем файл jQuery. У меня он лежит в тут же.
jsdom.jQueryify(window, './jquery-1.5.min.js', function (window, jQuery) {
// jQuery загружен, дальше ищем по телу документа
// Собственно each не нужен, но кусок был нагло выдран из контекста
jQuery('body').each(function () {
var sgf = jQuery(this).find('param[name|="sgf"]').val();
if (sgf) {
var id = jQuery(this).find('param[name|="id"]').val();
var difficult = jQuery(this).find("td.prob:contains('Difficulty:')").next().text();
// дальше обработчик строки с данными о сложности
var re = /(\w+)\s(\w+)/;
// Пишем в файл и срём в консоль
fs.writeFile(id+'_('+difficult.match(re)[0]+').sgf', sgf,function(err){
if (err) throw err;
console.log(id+'_('+difficult.match(re)[0]+').sgf saved!');
});
}
});

agent.next();

});

});

agent.addListener('stop', function (agent) {
sys.puts('the agent has stopped');
});

// Запускаем
agent.start()

Часть кода было нагло содрано и немного адаптированно, архитектура хромает. Но дело делает. С задачей справляется. Тем более, что для себя.

squeeze ssh -X couldn't open display

Если вылазит такая бага, то можно проверить наличие переменной DISPLAY, если пусто.
То тогда два варианта - нет xauth (что в общем-то странно), либо по случаю вы запретили ipv6 в sysctl. Пока это баг ssh. Для обхода в /etc/default/ssh в опциях добавить "-4"
Что заставит ssh ходить только ipv4

vmware-server && debian squeeze

Ну что же, дамы и господа, любители и профессионалы дистрибутивов дебианного базирования. В сегодняшнем посте хочу рассказать про такой продукт, как vmware-server 2.0.2. Кто не знает, эта штука условно бесплатная(до 10 хостов) и ключик можно получить на самом сайте изготовителя данного продукта. Что это такое рассказывать не буду, а вот как его есть пожалуй расскажу.
Новый дебианный год уже на носу, так что начинаем потихоньку встречать squeeze. И именно это долгожданное событие мне преподнесло сюрприз. Одним из исходов этого сюрприза стала связка vmware-server и squeeze.

apt-get install build-essential gcc-4.3 linux-headers

Зачем gcc-4.3? Варя ругается, что вот собрано у тебя все на 4.3, а стоит 4.4. И категорически отказывается что-либо делать дальше.
Дальше нам стоит рассказать системе, что у нас теперь 4.3
~# ln -sf /usr/bin/gcc-4.3 /usr/bin/gcc
Дальше забегаю на перед, прошу подредактировать файл
/etc/services:
vmware-authd 902/tcp

Дальше качаем варю и vix в сырцах. см. tar.gz на конце, а конец в файле, а файл на жестаке, а жестак на сервере. А как к серверу пройти и слово заветное какое, это у бабы яги спроси.

Дальше внимание качаем патч по адресу. Ну не хочет варя на 2.6.32 собираться, ей богу не хочет:

http://codebin.cotescu.com/vmware/vmware-server-2.0.x-kernel-2.6.3x-install.sh

А скачается архив raducotescu-vmware-server-linux-2.6.3x-kernel-release-1.5-1-g71f8b66.tar.gz Или что-то схожее.

Собственно распаковываем файлы из архива туда же, где находится дистрибутив с варей.
Если внимательно почитать патчевый установщик, то окажется, что работает он с убой, а вот простенький дебиан не знает. Что в принципе править, решать вам. Я не стал править
сам установщик, а просто добавил то, что он ждет. А ждет он /etc/*-release, я собственно взял таковой из убы 10.04 и вот собственно он
/etc/lsb-release:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.1 LTS"

А дальше запускаем
~# ./vmware-server-2.0.x-kernel-2.6.3x-install.sh
И практически везде отвечаем , но внимательно читаем, что он от вас хочет.

P.S.: пока не знаю, как ведет себя текущий веб-интерфейс, но в 2.0.1 он вел себя просто ужасно. Особенно ajax-форма авторизации.
P.P.S.: почему не привожу все команды в нормальный ctrl+insert shift+insert по двум причинам: почитаете меня, а так же можно встретить ради хохмы что-нибудь такое:
lrep -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'
#lrep понятно дело надо на perl поменять. Да и под рутом - самое то.
P.P.P.S.: автор настоятельно рекомендует перед выполнением последнего скрипта сделать полный бэкап системы, а для суровых челябинских юниксойдов настоятельно рекомендует делать бэкап файлового древа разделов. А так же, вообще рекомендую не выполнять последний скрипт.