Удаление записи из известных хостов SSH

Не секрет, что администраторам linux систем часто приходится с одного и того же компьютера (рабочей/домашней машинки, к примеру) ходить по ssh на разные хосты. Не стану рассказывать зачем есть папка .ssh в хомяке, собственно как и файлы known_hosts и authorized_keys - нормальному админу грех этого не знать :) Но часто бывает проблема (даже не проблема, - так неудобство) когда уже внесенный в known_hosts публичный ключ некоего хоста становится инвалидным (толи хост-машину поменяли, толи DNS запись или IP адрес перенесли). В таком случае Вы получаете сообщение вида: Естественно нужно понимать, что произошедшее - действительно легитимное изменение фингерпринта хоста, а не хакерская атака. И вот Вам нужно просто снести изменившуюся запись для того, чтобы при следующей попытке зайти на хост снова прошел обмен ключами. Почти всегда это делается руками, но есть простая команда для автоматизации процеса. (у меня cat ~/.ssh/known_hosts | wc -l показывает 98! и копаться в них выискивая нужный ключ - прото долго) вот, что может Вам помочь.

Быстрый консольный способ оценить скорость сетевого соединия в Linux

Предположим есть 2 хоста между которыми необходимо проверить скорость передачи данных. Такая задача возникает в случае необходимости периодически передавать между ними данные для понимания временнЫх издержек при передаче (это, к примеру, могут быть данные репликации MySQL для высоко нагруженной записями БД). Как оценить скорость, если под рукой только консоль? Очень просто, впрочем как и большинство таких задач в linux, просто не совсем очевидно :) Итак для тестов нам понадобятся утилиты nc и dd. На первом хосте (цель для передачи данных) запускаем: Запустили nc в listen mode на порту 12345 На втором хосте (передатчик данных )запускаем: В результате - получаете скорость передачи данных (от вывода dd)

NGINX. Редирект статики для серверов разработки

Дошли, наконец-то руки описать один прелестный прием в сервере nginx. И себе - чтобы не забыть, и Вам, чтобы пользовали.
Итак: имеем production сервер с веб порталом и несколько development серверов, используем git для создания распределенных сред разработки (с последующим мержингом веток разных разработчиков и деплоем на production сервер). Рассмотрим подробнее один из серверов разработчиков (любой, в данном случае), а именно как сделать некоторые полезности при разработке веб портала. Так вот: есть клон git репозитория с файлами скриптов (и прочего стаффа веб приложения) с которым все ясно - программист пишет, комитит, апдейтит и пр. Но вот вопрос как быть с тестами написанного? Самым простым и действенным решением есть развернуть на сервере разработчика весь сайт, который тот разрабатывает и тестируй себе на здоровье! Но вот вопрос со статикой сайта (картинки, css, js, и т.д.) остается открытым - делать 5-20 копий статики накладно, ведь может занимать много места на диске. Потому, используя nginx можно брать статику прямо с production сервера. Нагрузки на него много мы не сделаем, а вот хлама на development серверах будет порядком поменьше, да и проблемы с синхронизацие будут отброшены за ненадобностью.
Собственно вот рецепт: (приведу часть рабочего конфига nginx с пояснениями)
Вообще-то - никакой магии - просто средствами nginx проверяется наличие локально запрошенного файла и, в случае его отсутствия, - редирект на основной сайт.
Вот так вот.

Глупости админиские. На прицеле - 5й национальный канал Украины

Ну не смог удержаться и написать сей пост. (Оным ознаменую ряд статей о том как много у нас горе-админов)
Суть сегодняшнего поста: приходик ко мне бедный пользователь и говорит, что старательно отправляет почту на имя одного адресата в домене @5.ua  (по этическим соображениям не буду указывать кого именно), а ему письма то не доходят вовсе, то доходят но с каким-то искаженным содержимым, то в спам попадают, то ещё какие-то грабли с ним происходят.
Ну у бедного пользователя стоит Chrome и через него он логинится в Google Apps Mail и отправляет письмо в 3 строки (не HTML, нет вложенных файлов, - вообще - просто 3 строки по русски!), а письмо не доходит.
Ок - копаем: Феерично, не правда ли? Разбираем криворукость по частям:
0. Ну, видно, что почта переехала на Google Apps Mail - похвально!...
1. Не особенная проблема, но смотрится странно - MX priority 0 - можно, но лучше не делать. Во всех мануалах стоит начальное priority = 10, ну да ладно...
2. pri=45 mail.5.ua - вот тут начинается магия, - хост вообще не отвечает на SMTP запросы, тоесть, судя по доменному имени там был почтовик, но либо времненно умер (на мемент выявления проблемы), либо умер уже давно, но из DNS не убрали.
3. pri=50 h7.prohosting.com.ua - видимо SMTP хостера, где лежит сайт. Самое удивительное, что он принимает почту для домена @5.ua хотя она и переехала на гугл!!!
и что мы там видим?  Бедолага, который выгребает почту с GMAIL совершенно позабыл про то, что его почта частично поступает ещё и на SMTP сервер провайдера, о чем говорит сообщение о переполненности ящика! Отсюда вытекают его жалобы на, то что он чего-то не получает...

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

FALLBACK сервис для WEB портала - спасаемся от проблем!

В этом посте я постараюсь описать одну из техник применяемых мною в повседневной работе при администрировании web серверов. Быть может кому-либо будет полезным такой метод.
Итак, дано:

• есть web портал (php scripts/mysql databases/static files)
• необходимость минимального простоя в случае сбоев
• надобность иметь резервные копии содержимого портала

Вроде бы и так все понятно - резервные попии делаются по расписанию (день, месяц, год, ...), правильно (инкрементный бэкап, сбросы на ленту/DVD,...)- данные не потеряются! Чего ещё надо?

А вот вам ситуация, при чем далеко не гипотетическая: Ваш замечательный сайт http://www.mysupersite.com уже в первой десятке поисковой выдачи, народ валит к Вам на ресурс, реклама дает прибыль, - вобщем ляпота! Вы заглядывая в аналитикс не можете нарадоваться, и все у Вас правильно, и резервные попии и девелопмент сервер для программистов есть и вооще, - все как должно быть. Но тут, внезапно, сайт не отвечает, доступа к серверу нету, а саппорт хостера сообщает, что у них потоп/перегрев/вырубилась хост машина VPS/пропали каналы связи (нужное подчеркнуть) или в сервере сгорели винчестера (сразу 4 в RAID10 :) ) или ещё 100 причин по которым конечные пользователи портала его не видят. Кошмар! Надо что-то срочно сделать, - резервные копии есть, - разворачиваем новый сервак и понеслась...

Знакомо? Многим - наверняка да. Сколько времени потратили? от 1-го ... 2-х часов до нескольких суток (если физически вышли из строя комплектующие сервера, а нового нету).

Как я спасаюсь от этого? все просто - fallback web server! Идея была позаимствована (и немного модифицирована) из практик использованя fallback MTA (вторичный почтовый сервер который занимается отложенной отправкой писем электронной почты).

В общих чертах шаги которые надо проделать таковы:

1. Заводим второй сервер (физический, если Вы хотите в случае аварии на основном в полном объеме поднять сервис или VPS в случае если необходимо просто "перебится" пока восстанавливается основной сервер) желательно, конечно же не на одной хост площадке, дабы и резервный сервер не накрылся "медным тазом" при проблемах у хостера.
2. Делаем первичну полную синхронизацию сервисов (ставим такие же версии php/mysql/apache и т.д.), файлов (переносим конфигурации сервисов, статику сайта, скрипты сайта, user uploads и т.д.), баз данных (дампим/ресторим) - в общем делаем почти полностью зеркало сайта - отличатся они будут только адресами.
3. Включаем master-slave репликацию для MySQL (в моем случае. подробнее: http://dev.mysql.com/doc/refman/5.0/en/replication.html) или подобные техники в любом другом любимом Вами сервере баз данных. Важно, чтобы в результате данные в базах в любой момент времени были синхронны.
4. Пишем простецкие скрипты на bash с использованием rsync (подробнее: http://rsync.samba.org/) для синхронизации файлов на fallback сервер. Но, не забудьте грамотно выстроить процедуру синхронизации, так как  для очень большего количества файлов в проекте эта процедура может занять много времени, - стоит синхронизировать сайт частями в разное время (редко изменяющиеся скрипты сайта - раз в сутки ночью, файлы пользователей - раз в 1-2 часа.). Подскажу, сразу волшебную опцию для rsync: --bwlimit=<N> Kb/S - без неё вы просто "уложите" основной сайт при синхронизации данных!

Я умышленно не привожу готовых скриптов, примеров конфигураций и пр., для того, чтобы отсеять "linux эникейщиков" молодых администраторов не очень любящих думать своей головой.

После всего Вы получите сервер готовый в любой момент заненить вышедший из строя боевой. Как это сделать? Либо в мануальном режиме (заменить DNS/поменять IP на сервере если можно), либо в полуавтоматическом режиме (watchdog скрипт для мониторинговой системы), либо в полностью автоматическом (Keepalived/Heartbeat и прочие техники)

Каковы ещё выгоды от наличия такого сервера? Из очевидных:

• Возможность делать резервные копии с fallback сервера не нагружая при этом основной боевой, что очень критично при дампах баз, которые могут блокировать таблицы
• Быстрое восстановление работоспособности портала в случае серьёзных проблем на основном сервере.
• Возможность проводить тестирование новых сервисов портала в боевых условиях (с оглядкой на проблемы с репликацией баз данных, подробнее: http://dev.mysql.com/doc/refman/5.0/en/replication-features.html)
• Возможность при запредельной нагрузке на основной сервер, перераспределить нагрузку на fallback сервер. (я планирую написать отдельную статью про это)

К одной из неочевидных выгод (выявлены при экплуатации танных техник) относится выявление следов взлома основного сайта по синхронизированным файлам, которые взломщик использовал в ходе проникновения и потом удалил на основном сервере.

В любом случае - резервные копии  никогда не мешали! Удачи, - берегите сервера.

Политика использования паролей в Linux

"... всякий админ терпеть не может программистов за их безалаберность в отношении безопасности систем и кода; всякий програмер не меньше ненавидит админов за их параноидальные замашки в отношении той же безопасности..."
(с) народно-айтишная мудрость.

- Тебе не кажется подозрительным, что ты зашел на сервер в 5:32 утра?
- Я не заходил! Я спал... И вообще-то ночью люди спят!
- А какой был у тебя пароль на этоит сервер, тот что я тебе давал, rmQX0Nw3?
- Нет, я такой пароль запомнить не смог, потому поменял на другой!
- И какой-же он у тебя сейчас?
- Секурный, очень: 1q2w3e4r
- А попробуй сейчас войти по ssh и сообщи мне как успехи. ок?
- Не заходит, пишет Access denied, а почему так?
- Потому, Шарик, что ты балбес!...

(из общения админа и программиста какой-нить конторки)

Знакомо? Ещё нет? Ну, тогда лучше, чтобы такая ситуация и не произошла.
Как избавится? Вот простой рецепт, приготовить может каждый имея системные средства.

1. Меняем простецкие требования по умолчанию для паролей в linux. Для етого правим файлик /etc/pam.d/system-auth где имеется строка вида:
   password    requisite     pam_cracklib.so try_first_pass retry=3
   и добавляем к ней некоторые правила по сложности пароля, а именно:
   password    requisite     pam_cracklib.so try_first_pass retry=3 minlength=10 lcredit=1 ucredit=1 dcredit=1 difok=4
   что добавили:
   - minlength=10 - ну тут понятно.
   - lcredit=1 (lower case) - минимальное к-во строчных букв в пароле
   - ucredit=1 (upper case) - минимальное к-во заглавных букв в пароле
   - dcredit=1 (digits) - - минимальное к-во цифр в пароле
   - difok=4 - минимальное отличное от старых к-во символов, которые необходимо сменить при изменении пароля на новый.
   (подробнее http://linux.die.net/man/8/pam_cracklib)
   Тоесть мы, таким образом заставим пользователей создавать пароли не менее 10 символов в длинну, с минимум одной строчной, одной заглавной буквами и одной цифрой.
2. Заставляем нерадивых пользователей системы сменить пароль при следующем логине. Для это есть утилита chage в стандартном дистрибутиве linux (подробнее: http://linux.die.net/man/1/chage)
   chage -M 0 -d <yesterday-YYYY-MM-DD> <user-login>
   для желающих автоматизировать процесс, как домашнее задание - написание скрипта, который будет находить пользователей (c uid >= 500) и применять к ним эту команду

 Ну и конечно же необходимо поставить какую-то софтинку для отлова и блокирования злосных брутфорсеров, к примеру, - denyhosts (http://denyhosts.sourceforge.net/) для того, чтобы не сильно досаждали и не смоли подобрать какие-то словарные пароли в стиле 1q2w3e4r .
Берегите свои системы, свои данные и свои нервы! Успехов.

G-WAN - модно, быстро, интересно!

Сегодня расскажу про G-WAN (http://gwan.ch/) - быстрый web сервер с закрытым кодом. Спасибо, в очередной раз, энтузиастам выпускающим интересные вещи, а именно сию поделку, которая без преувеличения поразила скоростью своей работы. Все администраторы web серверов так или иначе должны знать apache/nginx/lighttpd (не нужное зачеркнуть :) ) для того, чтобы вообще постороить web сервис. Но если эти киты индустрии давно на рынке, хорошо документированы, облизаны на всевозможных форумах и давно стали привычными в обиходе софтинками, то G-WAN представился "темной лошадкой" (проприентарный исходный код, вакуум в документации, минимум упоминаний на форумах и вообще - мало историй внедрений) после тестирования которой, так и захотелось на неё поставить!...

Итак:

• скачали (благо на сайте хоть и не самая свежая версия, но freeware)
• поставили (забудьте про configure/make - уже в бинарнике 32/64)
• настроили (только не теряйте голову сразу - тут нет привычного .conf файла, да и надобности в нем нету тоже)
• запустили (как говорится "из коробки")
• http://localhost:8080/?hello.c - вуаля, - вот вам и Hello World!

 Вся процедура занимает менее 3-х минут.

А теперь магия! Попробуйте проделать не сложный тест (предполагается, что у вас есть apache/nginx/lighttpd настроенный и работающий) - положить статическую картинку весом в 75к байт и запустить apache benchmark (ab):

ab -c 500 -n 10000 http://www.your-site.com/cool-image.png

как думаете что будет (если пренебречь ограничением по tcp сокетам, которые в среднем израсходуются где-то к 6-8к запросам)? Индеец загнется почти сразу остальные побарахтаются, но выдадут до 80% ошибок в ответах. А вот для G-WAN это вообще не проблема! Не спрашивайте как это работает (исходных кодов нету), но это работает!

Интересно? Продолжаем!

Вот как выглядит исходный код скрипта в ссылке (http://localhost:8080/?hello.c):

#include "gwan.h" // G-WAN exported functions

int main(int argc, char *argv[])
{
   xbuf_cat(get_reply(argv), "Hello World (C)");

   return 200; // return an HTTP code (200:'OK')
}

да, именно - это С! Тоесть вместо PHP/Perl и прочих скриптовых языков с медленными обработчиками, Вы можете писать сайт прямо на С/С++ и он будет работать в сотни раз быстрее, добавим к этому технологию edit & play (автоматическая перекомпиляция кода при правках) и получим некое подобие PHP для С-шников :) Вы спросите, а чем собственно это лучше чем CGI/FastCGI? А тем, что при изменении С кода Вам не нужна перекомпиляция (G-WAN делает это атоматом), в скрипте можно использовать массу встроенных в сервер возможностей как то: аналог memcache и прочее (полный перечень можно найти на сайте или в презентации http://gwan.ch/archives/g-wan_prez.pdf)

На данный момент я занимаюсь тестированием и возможностью внедрения сервера в production окружение. Пока только как static content server для других нагруженных проектов, но в дальнейшем в планах есть освоить методику написания сервлетов для этого сервера и использовать его для отдачи динамического контента.

Больше по теме:
http://www.wikivs.com/wiki/G-WAN_vs_Nginx

Ждите продолжения!

Генерация паролей в *nix - это просто!

Хотелось бы увековечить некий замечательный инструмент системного администратора *nix систем, а именно - простой, не требующий никаких дополнительных средств, кроме встроенных в систему утилит, генератор паролей.

вот такой вот прекрасный shell скрипт для генерации паролей:

i=0; while [ $i -lt <pass_cnt> ]; do  cat /dev/urandom | tr -dc a-z0-9A-Z | head -c<pass_length> ; echo; let i=i+1; done

вобщем-то все гениальное просто:
У нас всегда есть /dev/urandom - в котором много псевдослучайного содержимого, - главное правильно вычленить из него то, что подходит для паролей (не загромождаем пароли всякими :, %, № и т.д. - выставим, что нам надо латинские буквы и цифры a-z0-9A-Z). Что нужно - так это заполнить числами <pass_cnt> - количество генерируемых паролей, <pass_length> - длинна генерируемого пароля. Вуаля!
Примерный вывод:

/home/eugene #i=0; while [ $i -lt 5 ]; do  cat /dev/urandom | tr -dc a-z0-9A-Z | head -c25 ; echo; let i=i+1; done
KuYJfTccG8LXTobjPAvonccQE
TYYWMoNxivCgX1BntWncATGWr
ocDyB9rMZ1mN6Et8EV3wmKiOa
u65z86ptl1ZlhCiGsVZ1s0XD7
tEO6zBn4dxUPtabFb7GrkjjrM

5 паролей, по 25 символов.

Для удобства можно выставить алиасы для bash:
alias pass10='i=0; while [ $i -lt 10 ]; do  cat /dev/urandom | tr -dc a-z0-9A-Z | head -c10 ; echo; let i=i+1; done'
alias pass20='i=0; while [ $i -lt 10 ]; do  cat /dev/urandom | tr -dc a-z0-9A-Z | head -c20 ; echo; let i=i+1; done'

NGINX Сервер по-умолчанию.

...дабы не забыть и потом использовать!..

   С точки зрения SEO, для рабочего web проекта с 20к+ посетителей в сутки очень резонно, чтобы не было возможности ходить на ваш любимый сайт по IP-based url. То есть: если есть сайт http://www.goodsite.com, то ссылки вида http://123.123.123.123 (собственно IP адрес сервера где находится ваш сайт) не должны существовать вообще или должны редиректится с кодом 301 на соответствующие разделы вашего сайта.
   Почему это плохо:
1. Много сайтов используют domain name из url для перехода в соответствующие под-домены, разделы и др. и при введении ip адреса в качестве domain name будут вести себя не предсказуемо.
2. Поисковыми машинами ссылки на http://www.goodsite.com и http://123.123.123.123 будут фактически индексироваться как разные сайты.

Как быть? Достаточно просто:
В повседневной работе я использую сервер nginx Игоря Сысоева в качестве фронтэнда для всех своих проектов и на нем реализация схемы с редиректами проходит достаточно легко.



Собственно рассказывать про rewrite в nginx я не буду - писано уже много (google it!). А вот сама суть в директиве server_name: если указать в качестве имени сервера _ (подчёркивание), то при обращении к не существующему виртуальному хосту, будет отрабатывать именно этот сервер. Ну а внутри него можно разрисовать несколько условий в том случае если у вас много виртуальных хостов.

Информационные технологии в нашем бизнесе. Часть первая: Искали админа? Вот он я!

Очень короткое предисловие.
Многое уже было написано, сказано и раскритиковано в этой теме. Не буду пытаться повторить кого-то (хотя, так или иначе получится ибо я не первый :) ), но очень хочется описать свой личный опыт и попытаться проанализировать как в Украине (а, впрочем, и в других странах ex-СССР) обстоят дела во взаимоотношениях бизнеса и IT с позиции тех кого называют компьютерщики, сис. админы, "программисты", инженеры компьютерных систем и пр. Хотя государство удостоило нас в КЗоТ-е всего-лишь странным словосочетанием "администратор систем" (каких? может машинного доения - не ясно...)
Намеренно оставим за бортом этого цикла постов крупный бизнес (банки/страховые и др.), системных интеграторов, провайдеров и прочие компании в которых от толкового IT департамента во многом зависит прибыль, стабильность работы, безопасность и прочее, - такие компании, в большинстве случаев очень тщательно отбирают персонал и понимают, что IT это не нахлебники, а полноценная часть бизнес процессов компании.

Часть первая: Искали админа? Вот он я!
Первый пост из цикла в котором рассмотрим такую ситуацию: Вы админ и приходите на работу в новую для себя компанию.
Умолчим пока о причинах которые вынуждают компании искать себе специалистов по системному администрированию, - таковые будут рассмотрены отдельным постом. Но вот, Вам понравились/подошли/не было другого выбора (лишнее зачеркнуть) условия описанные в вакансии компании и Вы шлете свое резюме.
И смех и грех №1: Описание вакансии - залог успеха!
Ну тут можно отдельные мемуары писать, но будем краткими, - в 75% случаев описание вакансии у толкового администратора вызывает улыбку. Ведь не зря имеется расхожая шутка о том, что если описание вакансии админа спроектировать на водителя, то получится что-то в духе: "Компании требуется водитель с открытыми категориями A1, A, B, C, D, E, ..., со стажем управления автомобилями почти всех известных марок, опытом слесаря, электрика, моториста, дизельщика, жестянщика. Обязательным является требование умения сконструировать свой собственный двигатель внутреннего сгорания. Плюсом будет опыт участия в ралли и Формуле 1. Испытательный срок - 3 мес. Оклад - 2000 грн., после испытательного срока - 2500 грн.".
Ну, право же, - смешно!
Достаточно часто встречаются описания вакансий для системных администраторов написанных людьми настолько далекими от IT, что в итоге получается просто ахинея, ну вот, к примеру, "... необходимые знания: DHCP, DNS, FTP, VPN, ISDN, OSI, TCP, Internet...". То есть - нашли много интересных сокращений (знакомый/бывший админ сказал написать именно так!) и разместили вакансию... Или вот ещё: "Обязательные знания: Ubuntu linux, 1C Предприятие 7.7" - как вам такая связка? Ну и чтобы совсем добить, вот такое: "управление 8 ПК с Windows, настройка сети, общего доступа; обязательно наличие сертификата CCNA", и т.д. В общем-то много есть подобных перлов на сайтах по трудоустройству, - читатель может ознакомится с такими "вакансиями" потратив 10-15 минут.
И смех и грех №2: Кто приходит на собеседования? Резюме - наше все!
Итак, на такую вакансию, как описано выше, откликается соискатель. В 90% приходит на почту резюме, да еще и какое! ого! 2-3 страницы печатного текста с подробным описанием типа: "доскональные знания MS Windows XP, Vista, 7, MS Word, Excel, PowerPoint, Photoshop, Прокладка сетей, настройка Internet, WiFi, 1C, ...." - ну не администратор - находка! все знает, и работал и там и сям - опыт того и сего. "Да все могу! да я делал это уже 100500 раз! да это легко!". Приходит такой человек на собеседование (кстати проводит его та же секретарша, которая текст "вакансии" создавала), и вот основным вопросом остается только З/П. Сходили к директору - пара вопросов - напутствие и в бой! Правда не всегда интересуются, а почему так много мест работы со сроком менее полугода...

Мне приходилось искать на работу системных администраторов (в свою компанию, друзьям, просто подсказывать знакомым годится ли тот или иной человек им на работу) и картина складывается просто удручающая: во время кризиса 2008-09 годов банки, страховые компании, средний бизнес уволили толпу псевдо системных администраторов. Кто это такие? В 75% случаев - студенты старших курсов, которые, научившись хоть как-то  делать такие вещи как:
1. ставить windows - спросите у них, что такое tcp/445 порт в системе? или что такое принт-сервер?
2. настраивать сеть - спросите что за маска под-сети такая хитрая 255.255.224.0? или вот, - зачем нужна команда route?
3. ставить софт - обязательно спросите какие альтернативы есть для MS Word? или ставил ли человек хоть раз нормальный лицензионный продукт?
4. управлять базами данных - спросите в чём разница между MS SQL и MY SQL?
5. закупать оборудование - спросите про разницу между SATA и SAS? или что такое tape autoloader?
6. создавать IT инфраструктуру - спросите что такое firewall? или почему в том или ином сервере должно быть именно 16Гб ОЗУ?
и т.д.
Ответы на эти простенькие вопросы таких вот псевдо админов порадуют своей богатой гаммой тупостей.

Плодами работы вот таких вот "товарищей" на мелкий и средний бизнес становятся бестолково настроенные офисные инфраструктуры, тысячи в пустую потраченных гривен, простои в работе компаний в результате постоянных сбоев, отсутствие актуальных резервных копий критичных данных, и, в итоге - абсолютный негатив по отношению к самой профессии системного администратора. Ещё одним побочным эффектом работы таких людей является устоявшееся мнение, что админ это человек "принеси-подай": ведь если посмотреть с точки зрения руководства - сидит человек ничего не делает/создает видимость работы (таковы уж реалии - если все более менее правильно настроено - работы не много) - пусть хоть что-то сделает, - лампочки заменит, груз поднимет, приберёт и т.д....


(Продолжение следует)