Мое видение:
Везде написано что "Эникей" - продвинутый пользователь, в должность которого входит техническая поддержка пользователей ПК, а также переустановка/установка драйверов, приложений, операционной системы на ПК, замена картриджей и т.д., ну и по желанию работодателя - занятие всякой потусторонней электроникой/приборами. Но как мне кажется, грань лежит не в области деятельности, а вовсе в другом - в наличии знаний, практического опыта, в подходе к решению проблем.
Ну и после трех лет работы "эникеем" в классическом понимании, у меня появилось какое-то странное ощущение:
1. Сама по себе работа неинтересна, однообразна и скучна, а оплачивается довольно-таки скудно. При этом должность все равно называется "системный администратор".
2. Эникей не только не прогрессирует с определенного момента, но даже деградирует.
3. Эникеи не занимаются самообучением.
Вот почему-то встречались мне люди, которые:
1. Регулярно устраняют следствия проблем, вместо того чтобы раз и навсегда разобраться с их причинами. Классика жанра - трижды умирающая на одном и том же сервере БД, для которой нет актуальной резервной копии, потому что скрипт бекапа делает заведомо поврежденную копию базы.
2. Регулярно задают вопросы, ответы на которые находятся в Google ближайшему "гуру", причем иногда вопросы начинают повторяться.
3. Вообще не умеют задавать вопросы. Это вообще повергло меня в шок - как это, заниматься техподдержкой и не уметь задавать вопросы? Они смеются над бухгалтерами но в то же время сами спрашивают "Стас, у наших операторов тут какая-то хрень выскакивает, ты не знаешь что это может быть"?
4. Как следствие из моего описания эникея - действительно, не прогрессируют и предпочитают все списывать на "глюки винды", не знают фундаментальных понятий и принципов работы железа, ПО и сетей, не способны к автоматизации рутинной работы.
Да, они называются "Системными администраторами", хотя на самом деле это и есть так называемые "эникеи".
Естественно противоположность этому - это и есть сисадмины, потенциальные или уже практически готовые.
пятница, 30 января 2009 г.
среда, 28 января 2009 г.
вторник, 27 января 2009 г.
Почему GNU su не поддерживает группу "wheel"
Перевод статьи Why GNU su does not support the “wheel” group
(Из страницы руководства GNU su)
22.5.1 Почему GNU su не поддерживает группу “wheel”
(Эта секция написана Ричардом Столлманом.)
Иногда несколько пользователей пытаются удержать свою власть над всем. Например, в 1984, несколько пользователей в лаборатории искусственного интеллекта MIT решили отобрать власть путем смены пароля оператора на системе Twenex и хранили его в секрете от всех остальных. (Я был способен исправить это и вернуть власть пользователям путем исправления ядра, но я не знал, как сделать это в UNIX).
Однако, иногда правители пробалтываются. Используя обычный механизм su, когда кто-нибудь узнает пароль root и симпатизирует обычным пользователям, он или она могут рассказать остальным. "wheel group" делает это невозможным, и это цемент для власти правителей.
Я на стороне масс, а не правителей. Если вы регулярно поддерживаете боссов и сисадминов, что бы они не делали, вы можете найти эту идею немного странной.
(Из страницы руководства GNU su)
22.5.1 Почему GNU su не поддерживает группу “wheel”
(Эта секция написана Ричардом Столлманом.)
Иногда несколько пользователей пытаются удержать свою власть над всем. Например, в 1984, несколько пользователей в лаборатории искусственного интеллекта MIT решили отобрать власть путем смены пароля оператора на системе Twenex и хранили его в секрете от всех остальных. (Я был способен исправить это и вернуть власть пользователям путем исправления ядра, но я не знал, как сделать это в UNIX).
Однако, иногда правители пробалтываются. Используя обычный механизм su, когда кто-нибудь узнает пароль root и симпатизирует обычным пользователям, он или она могут рассказать остальным. "wheel group" делает это невозможным, и это цемент для власти правителей.
Я на стороне масс, а не правителей. Если вы регулярно поддерживаете боссов и сисадминов, что бы они не делали, вы можете найти эту идею немного странной.
понедельник, 26 января 2009 г.
Как запустить VMWare ESXi в VMWare Workstation?
Эта возможность появилась начиная с Workstation версии 6.5. )
Достаточно подробная инструкция.
Работает, конечно, не быстро, но оценить возможности ESX позволяет. Рекомендую попробовать тем, кто еще не знает, что такое ESX или хочет, но не имеет подходящего оборудования для запуска ESXi, а посмотреть хочется.
К слову, ESXi для требует двухядерной машины с SCSI контроллером жестких дисков - так что дома его запустить без другой виртуальной машины вряд-ли удастся владельцу обычного компьютера.
Достаточно подробная инструкция.
Работает, конечно, не быстро, но оценить возможности ESX позволяет. Рекомендую попробовать тем, кто еще не знает, что такое ESX или хочет, но не имеет подходящего оборудования для запуска ESXi, а посмотреть хочется.
К слову, ESXi для требует двухядерной машины с SCSI контроллером жестких дисков - так что дома его запустить без другой виртуальной машины вряд-ли удастся владельцу обычного компьютера.
суббота, 24 января 2009 г.
OpenVPN: очень быстрый старт
Наиболее быстрый и простой способ организовать VPN-соединение с клиентом, который спрятался за чем угодно кроме прокси - это OpenVPN. Он не использует никаких сложных "управляющих" и "передающих данные" соединений, как это делает PPTP, поэтому идеально подходит в случаях, когда ваш маршрутизатор не умеет нормально пробрасывать GRE (или вы не знаете, как его настроить). Ну и прост в настройке в любой поддерживаемой операционной системе.
Все что нужно сделать - это написать простой конфигурационный файл, сгенерировать ключ и запустить серверную и клиентскую часть.
На примере debian или ubuntu:
1. Устанавливаем OpenVPN (одинаково на сервере и на клиенте):
Настраиваем сервер:
1. Создаем вот такой вот /etc/openvpn/openvpn.conf:
После этого генерируем общий ключ для соединения:
Заметим, что он сразу создается с правильными правами - только root может прочитать его.
Перезапускаем OpenVPN:
Настраиваем клиента:
/etc/openvpn/openvpn.conf
Осталось только скопировать openvpn.key с сервера на клиента и перезапустить OpenVPN на клиенте:
Если что-то не работает, сначала смотрим лог (/var/log/openvpn.log).
Все что нужно сделать - это написать простой конфигурационный файл, сгенерировать ключ и запустить серверную и клиентскую часть.
На примере debian или ubuntu:
1. Устанавливаем OpenVPN (одинаково на сервере и на клиенте):
# aptitude install openvpn
Настраиваем сервер:
1. Создаем вот такой вот /etc/openvpn/openvpn.conf:
# Использовать tun-интерфейсы вместо tap dev tun # Локальный IP и IP дальней стороны туннеля ifconfig 192.168.111.1 192.168.111.2 # Местоположение общего ключа secret /etc/openvpn/openvpn.key # Порт клиента и сервера port 1194 # Используемый транспортный протокол proto udp # Сжимаем пакеты с помощью lzo, используя адаптирующийся алгоритм. comp-lzo # проверяем работу туннеля каждые 10 секунд и перезапускаем в случае обрыва через 60 keepalive 10 60 # Не проверять таймауты, если клиент не подключен ping-timer-rem # не выключаем интерфейс при перезапуске соединения persist-tun # Очень полезная опция - не перечитывать ключ при рестарте соединения. # Дело в том что OpenVPN может снижать привелегии (см ниже) при запуске после # чтения конфигурационного файла и ключа в целях безопасности. persist-key # Пользователь, под которым работает демон после запуска user nobody # Собственно, становиться ли демоном daemon # Куда пишем журнал. log-append /var/log/openvpn.log
После этого генерируем общий ключ для соединения:
# openvpn --genkey --secret /etc/openvpn/openvpn.key
Заметим, что он сразу создается с правильными правами - только root может прочитать его.
Перезапускаем OpenVPN:
# /etc/init.d/openvpn restart
Настраиваем клиента:
/etc/openvpn/openvpn.conf
# Единственная строка, которая отличает клиента от сервера - адрес удаленной стороны remote our.openvpn.server dev tun # Здесь адреса концов туннеля просто меняются местами ifconfig 192.168.111.2 192.168.111.1 secret /etc/openvpn/openvpn.key port 1194 proto udp comp-lzo keepalive 10 60 ping-timer-rem persist-tun persist-key user nobody daemon log-append /var/log/openvpn.log
Осталось только скопировать openvpn.key с сервера на клиента и перезапустить OpenVPN на клиенте:
# /etc/init.d/openvpn restart
Если что-то не работает, сначала смотрим лог (/var/log/openvpn.log).
четверг, 22 января 2009 г.
МТС-Коннект
Так уж складывается, что каждый год в районе нового года у меня улучшаются качества беспроводного интернета.
В 2007 году у меня вообще появился такой интернет - через GPRS, все знают его скорости и задержки - на самом деле это около 6 кБ/с и в среднем RTT пакета составляет около 1000 мс. К концу года качество этой услуги упало катастрофически ). Частые разрывы связи, ухудшение RTT, вот как это стало выглядеть.
В 2008 году он вырос до EDGE, выросла только скорость, максимум до 30 кБ/с. Поначалу - без разрывов, скорость оставалась более-менее приличной. Качал гигабайтами в месяц. ) Но потом качество услуг стало ухудшаться. Появились потери пакетов, скорость упала, часто до уровня GPRS, несмотря на наличие покрытия EDGE. Я перестал принимать звонки во время работы в Internet. Нужно было что-то менять.
И вот, в 2009 году я заменил его на CDMA. Приобрел комплект "МТС Коннект", протестировал. В среднем качество связи удовлетворительное (но иногда все-таки пропадает сигнал, неожиданно и неизвестно куда), что особенно радует - RTT упал до 100-200 миллисекунд, так что стало проще работать с такими вещами как SSH и RDP... опять же, телефон свободен от интернета вообще. Единственное, что плохо - траффик стал несколько дороже. Но и скорость выросла - около 850кб/с вниз и 100кб/с вверх, не пределы конечно, но лучше чем было...
В 2007 году у меня вообще появился такой интернет - через GPRS, все знают его скорости и задержки - на самом деле это около 6 кБ/с и в среднем RTT пакета составляет около 1000 мс. К концу года качество этой услуги упало катастрофически ). Частые разрывы связи, ухудшение RTT, вот как это стало выглядеть.
В 2008 году он вырос до EDGE, выросла только скорость, максимум до 30 кБ/с. Поначалу - без разрывов, скорость оставалась более-менее приличной. Качал гигабайтами в месяц. ) Но потом качество услуг стало ухудшаться. Появились потери пакетов, скорость упала, часто до уровня GPRS, несмотря на наличие покрытия EDGE. Я перестал принимать звонки во время работы в Internet. Нужно было что-то менять.
И вот, в 2009 году я заменил его на CDMA. Приобрел комплект "МТС Коннект", протестировал. В среднем качество связи удовлетворительное (но иногда все-таки пропадает сигнал, неожиданно и неизвестно куда), что особенно радует - RTT упал до 100-200 миллисекунд, так что стало проще работать с такими вещами как SSH и RDP... опять же, телефон свободен от интернета вообще. Единственное, что плохо - траффик стал несколько дороже. Но и скорость выросла - около 850кб/с вниз и 100кб/с вверх, не пределы конечно, но лучше чем было...
среда, 21 января 2009 г.
Microsoft Visual Basic for Applications
Удивительная технология, вызывающая у меня только один вопрос - а как отлаживать приложения, которые написаны с помощью VBA?
Для тех, кто не понял, в чем состоит вопрос ).
Обычно выполнение моего кода по пустяковым причинам заканчивается диалоговым окном с содержимым вида "400", "Object required" и подобными. Без указания даже строки, в которой случается ошибка. Ну строку ладно, можно построчным выполнением. Но причину узнать обычно можно только эмпирическим путем... а работавший вчера код в то же время сегодня может перестать работать. Неужели нельзя было ловить экспепшены внутри методов объектов и выводить внятные сообщения? А? Ну не садизм ли?
В общем, это и правда мой "дембельский аккорд" на старом месте работы, и никогда больше мне бы не хотелось сталкиваться с VBA.
Для тех, кто не понял, в чем состоит вопрос ).
Обычно выполнение моего кода по пустяковым причинам заканчивается диалоговым окном с содержимым вида "400", "Object required" и подобными. Без указания даже строки, в которой случается ошибка. Ну строку ладно, можно построчным выполнением. Но причину узнать обычно можно только эмпирическим путем... а работавший вчера код в то же время сегодня может перестать работать. Неужели нельзя было ловить экспепшены внутри методов объектов и выводить внятные сообщения? А? Ну не садизм ли?
В общем, это и правда мой "дембельский аккорд" на старом месте работы, и никогда больше мне бы не хотелось сталкиваться с VBA.
Подписаться на:
Сообщения (Atom)