Архив метки: altlinux

Мониторинг файловой системы в Linux. Inotify.

Для мониторинга событий файловой системы, таких как доступ к файлам, их модификация, создание/удаление, в Linux существует механизм под названием inotify. Он позволяет быстро и эффективно, в реальном времени мониторить указанные директории или отдельные файлы на заданные события и при их наступлении передавать информацию отслеживающим её приложениям. Читать

Мониторинг аппаратных датчиков в Linux. Linux-monitoring sensors (lm_sensors).

lm_sensors — ПО, используемое в *nix системах для получения данных с аппаратных датчиков о температуре компонентов, напряжении питания или скорости вращения вентиляторов, а так же задания минимального и максимального значения для каждого датчика, при достижении которого система начинает издавать звуковые сигналы через pc speaker (что не всегда является хорошей идеей).
Установка:
# apt-get install lm_sensors3
Прежде чем смотреть, каковы значения датчиков, эти датчики нужно сначала найти, используя утилиту sensors-detect. А чтобы она не спрашивала у вас десятки раз, согласны ли вы просканировать тот или иной узел аппаратной платформы, нужно сразу сказать ей да, с помощью утилиты yes:
# yes | sensors-detect
Утилита найдёт все датчики в системе и активирует необходимые для их работы модули ядра.
Теперь можно посмотреть данные, передаваемые датчиками с помощью утилиты sensors:
# sensors
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +37.0°C (high = +80.0°C, crit = +100.0°C)
Core 0: +34.0°C (high = +80.0°C, crit = +100.0°C)
Core 1: +36.0°C (high = +80.0°C, crit = +100.0°C)
Core 2: +27.0°C (high = +80.0°C, crit = +100.0°C)
Core 3: +30.0°C (high = +80.0°C, crit = +100.0°C)
it8728-isa-0a30
Adapter: ISA adapter
in0: +0.08 V (min = +0.00 V, max = +3.06 V)
in1: +2.02 V (min = +0.00 V, max = +3.06 V)
in2: +2.00 V (min = +0.00 V, max = +3.06 V)
in3: +2.03 V (min = +0.00 V, max = +3.06 V)
in4: +0.01 V (min = +0.00 V, max = +3.06 V)
in5: +1.79 V (min = +0.00 V, max = +3.06 V)
in6: +1.55 V (min = +0.00 V, max = +3.06 V)
3VSB: +3.38 V (min = +0.00 V, max = +6.12 V)
Vbat: +3.14 V
fan1: 802 RPM (min = 0 RPM)
fan2: 857 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
temp1: +27.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp2: +127.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp3: +28.0°C (low = +127.0°C, high = +127.0°C) sensor = Intel PECI
intrusion0: ALARM
Много не нужной информации и некоторые из значений не корректны, поэтому надо всё это дело настроить! Системный файл конфигурации редактировать не стоит, так как он заменяется при обновлении программы. Для локальной конфигурации создана папка /etc/sensors.d, в которой мо
жно создавать свои конфиги. Файл может иметь любое имя, это не важно, и будет перекрывать настройки системного файла, если в нём уже есть конфиги для настраиваемого оборудования. Создадим файл с красивым именем /etc/sensors.d/sensors.local.conf, а исходные данные для настройки возьмём из уже выполненной ранее команды sensors, и той же команды, с аргументом -u, что даст больше информации:
# sensors -u
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:
temp1_input: 36.000
temp1_max: 80.000
temp1_crit: 100.000
temp1_crit_alarm: 0.000
Core 0:
temp2_input: 35.000
temp2_max: 80.000
temp2_crit: 100.000
temp2_crit_alarm: 0.000
Core 1:
temp3_input: 36.000
temp3_max: 80.000
temp3_crit: 100.000
temp3_crit_alarm: 0.000
Core 2:
temp4_input: 27.000
temp4_max: 80.000
temp4_crit: 100.000
temp4_crit_alarm: 0.000
Core 3:
temp5_input: 31.000
temp5_max: 80.000
temp5_crit: 100.000
temp5_crit_alarm: 0.000
it8728-isa-0a30
Adapter: ISA adapter
in0:
in0_input: 0.036
in0_min: 0.000
in0_max: 3.060
in0_alarm: 0.000
in0_beep: 0.000
in1:
in1_input: 2.016
in1_min: 0.000
in1_max: 3.060
in1_alarm: 0.000
in1_beep: 0.000
in2:
in2_input: 2.004
in2_min: 0.000
in2_max: 3.060
in2_alarm: 0.000
in2_beep: 0.000
in3:
in3_input: 2.028
in3_min: 0.000
in3_max: 3.060
in3_alarm: 0.000
in3_beep: 0.000
in4:
in4_input: 0.012
in4_min: 0.000
in4_max: 3.060
in4_alarm: 0.000
in4_beep: 0.000
in5:
in5_input: 1.788
in5_min: 0.000
in5_max: 3.060
in5_alarm: 0.000
in5_beep: 0.000
in6:
in6_input: 1.548
in6_min: 0.000
in6_max: 3.060
in6_alarm: 0.000
in6_beep: 0.000
3VSB:
in7_input: 3.384
in7_min: 0.000
in7_max: 6.120
in7_alarm: 0.000
in7_beep: 0.000
Vbat:
in8_input: 3.144
fan1:
fan1_input: 802.000
fan1_min: 0.000
fan1_alarm: 0.000
fan1_beep: 1.000
fan2:
fan2_input: 857.000
fan2_min: 0.000
fan2_alarm: 0.000
fan2_beep: 1.000
fan3:
fan3_input: 0.000
fan3_min: 0.000
fan3_alarm: 0.000
fan3_beep: 1.000
fan4:
fan4_input: 0.000
fan4_min: 0.000
fan4_alarm: 0.000
fan4_beep: 1.000
fan5:
fan5_input: 0.000
fan5_min: 0.000
fan5_alarm: 0.000
fan5_beep: 1.000
temp1:
temp1_input: 27.000
temp1_max: 127.000
temp1_min: 127.000
temp1_alarm: 0.000
temp1_type: 4.000
temp1_offset: 0.000
temp1_beep: 1.000
temp2:
temp2_input: 127.000
temp2_max: 127.000
temp2_min: 127.000
temp2_alarm: 0.000
temp2_type: 4.000
temp2_offset: 0.000
temp2_beep: 1.000
temp3:
temp3_input: 28.000
temp3_max: 127.000
temp3_min: 127.000
temp3_alarm: 0.000
temp3_type: 6.000
temp3_offset: 92.000
temp3_beep: 1.000
intrusion0:
intrusion0_alarm: 1.000
Итак, прежде чем настраивать датчики, нужно задать чип, на котором эти датчики находятся. В примере, указанном выше, чипа 2 — coretemp-isa-0000 и it8728-isa-0a30. Указав чип, приступаем к настройке — скроем вывод данных ,которые, лично мне, не интересны. Это данные об отсутствующих вентиляторах (fan3-5), о напряжении питания разных модулей системы или о не подключённых датчиках температуры (temp2). Для игнорирования их вывода, используется опция ignore в сочетании с именем объекта:
chip «coretemp-isa-0000»
#IGNORE
ignore in0
ignore in1
ignore in2
ignore in3
ignore in4
ignore in5
ignore in6
ignore in7
ignore in8
ignore intrusion0
ignore fan3
ignore fan4
ignore fan5
ignore temp2
Теперь настроим вентиляторы fan1 и fan2 на том же чипе, которые показывают в 2 раза меньшее количество оборотов, чем это есть в реальности. С помощью опции compute, можно производить арифметические операции со значением указанного датчика:
compute fan1 2*@, @/2
compute fan2 2*@, @/2
Также есть опция label, с помощью которой можно переопределить название датчика, если оно определяется не корректно, либо просто хочется улучшить его челевекочитаемость:
label temp1 «CPU»
Нужно учитывать, что опция label работает как ожидается при использовании команды sensors, но может игнорироваться при использовании lm_sensors сторонними программами, например collectd эту опцию игнорирует.
Как уже упоминалось ранее, по умолчанию, демон lm_sensors подаёт звуковой сигнал на pc speaker при достижении заданного критического минимального или максимального значения датчика температуры либо если значение опускается до заданного значения датчика вентилятора. Пример этих значений (fan1_min: 0.000 у fan1 и temp1_max: 127.000 temp1_min: 127.000 у temp1):
fan1:
fan1_input: 1584.000
fan1_min: 0.000
fan1_alarm: 0.000
fan1_beep: 1.000
temp1:
temp1_input: 27.000
temp1_max: 127.000
temp1_min: 127.000
temp1_alarm: 0.000
temp1_type: 4.000
temp1_offset: 0.000
temp1_beep: 1.000
Эти значения можно корректировать, отключать звуковую сирену для конкретного датчика, либо вообще отключать звуковое оповещение глобально, так как это не всегда нужно.
Для корректировки значений есть опция set, используемая вместе с параметром и новым значением для этого параметра. Например, зададим параметру temp1_max значение 95:
set temp1_max 95
Отключим звуковой сигнал тревоги у вентилятора fan1_beep:
set fan1_beep 0
Либо отключим звуковой сигнал тревоги глобально для всех датчиков:
set beep_enable 0
(!) Для применения новых параметров, заданных опцией set, нужно выполнить команду sensors -s.
Конфиг, который получился у меня для использования совместно с collectd и материнской платой Gigabyte H87M-D3H:
chip «it8728-isa-0a30»
#FANS
compute fan1 2*@, @/2
compute fan2 2*@, @/2
#IGNORE
ignore in0
ignore in1
ignore in2
ignore in3
ignore in4
ignore in5
ignore in6
ignore in7
ignore in8
ignore intrusion0
ignore fan3
ignore fan4
ignore fan5
ifnore temp2

Автор: Yar4e

Автозапуск скрипта при загрузке ОС с помощью Systemd на примере x11vnc. Service-файлы.

Автозапуск скрипта при загрузке ОС с помощью Systemd на примере x11vnc. Service-файлы.

С массовым переходом на systemd, вопрос запуска скрипта от имени пользователя root при загрузке ОС, стал всё чаще подниматься на форумах и в умах линуксоидов, которым ещё не приходилось сталкиваться с этой новой системой инициализации. Меня этот вопрос так же не обошёл стороной, когда пришлось внедрять корпоративный дистрибутив, использующий systemd и появилась необходимость запускать при загрузке ОС x11vnc от имени пользователя root. Выяснилось, что в systemd, эта задача решается с помощью service-файлов, имеющих простой для понимания формат и создаваемых по стандартному, для этих целей, шаблону. Файлы эти располагаются в /lib/systemd/system (системные) и /etc/systemd/system (эта директория приоритетнее первой для systemd) и имеют имена вида: название.service. Загляните в эти директории, просмотрите несколько service-файлов имеющих знакомые названия типа network.service или cups.service и в общих чертах всё станет ясно. Содержание созданного мной service-файла таково:

[root@comp-core-2-81b58d system]# cat startvncserver.service
[Unit]
Description=Start vnc server /usr/bin/startvncserver

[Service]
Type=oneshot
ExecStart=/usr/bin/startvncserver
RemainAfterExit=yes

[Install]
WantedBy=graphical.target

Где, Description=Start vnc server /usr/bin/startvncserver — Описание сервиса.
Type=oneshot — Задание метода окончания периода запуска сервиса. Oneshot означает что действие, выполняемое сервисом должно быть окончено до запуска следующего сервиса.
RemainAfterExit=yes — Используется в связке с предыдущей опцией и говорит systemd о том, что данный сервис хоть и завершит свою работу после выполнения скрипта, но должен оставаться со статусом active.
ExecStart=/usr/bin/startvncserver — Путь к скрипту для выполнения.
WantedBy=graphical.target — Параметр, который даёт понять systemd, на какой стадии загрузки системы нужно выполнить данный сервис.  multi-user.target соответствует init3. graphical.target соответствует init5.

Для запуска, остановки, перезапуска, просмотра статуса  и включения в автозгрузку сервиса (и соответственно нашего скрипта), используются стандартные команды systemd.
Запустить:

[root@comp-core-2-81b58d system]# systemctl start startvncserver.service

Остановить:

[root@comp-core-2-81b58d system]# systemctl stop startvncserver.service

Перезапустить:

[root@comp-core-2-81b58d system]# systemctl restart startvncserver.service

Посмотреть статус:

[root@comp-core-2-81b58d system]# systemctl status startvncserver.service

И самое важное! Для запуска сервиса при загрузке ОС, его нужно включить:

[root@comp-core-2-81b58d system]# systemctl enable startvncserver.service

С автозагрузкой скрипта разобрались, теперь разберём сам скрипт и опции запуска vnc сервера x11vnc. В нашем случае, подключаются клиенты только из локальной сети, поэтому шифрование мы не используем. Из необходимых требований — запрет завершения процесса от имени пользователя и запрет чтения пароля на подключение пользователем. Поэтому мы запускаем x11vnc от имени root и храним пароль в файле, доступном на чтение только ему.

[root@comp-core-2-81b58d system]# cat /usr/bin/startvncserver

#!/bin/bash
while [[ $(test -f /var/run/xauth/A* ; echo $?) -ne 0 ]]
do
sleep 1s
done
/usr/bin/x11vnc -noipv6 -shared -forever -passwdfile /etc/x11vncpasswd -bg -display :0 -auth /var/run/xauth/A*

Где, используя цикл while мы задаём проверку того, появился ли файл «магической печенки», необходимый для запуска vnc сервера и если он ещё не появился, то ждём 1 секунду и проверяем вновь. Когда необходимый файл появляется, запускаем x11vnc со следующими опциями:

-noipv6 — Не использовать ipv6.
-shared — Обеспечить возможность подключения одновременно нескольких клиентов. Без этой опции, при подключении одного клиента, второй уже подключиться не сможет.
-forever — Не завершать работу сервера после подключения первого клиента.
-passwdfile /etc/x11vncpasswd — Указать, где искать пароль для подключения. Пароль содержится в текстовом файле, без шифрования, либо создаётся командой x11vnc -storepasswd в интерактивном режиме и записывается в файл ~/.vnc/passwd в шифрованном виде. При использовании первого варианта, нужно выставить права на чтение файла только пользователю root и соответственно запускать x11vnc от имени root, что я в общем и описываю.
-bg — запустить процесс на заднем фоне, то есть отвязать его от текущего терминала.
-display :0 — номер дисплея для подключения. По умолчанию в одномониторных системах это :0.
-auth /var/run/xauth/A* — путь к файлу с магической печенкой 🙂 То есть файлу авторизации X сервера. Где он лежит в вашей системе, можно выяснить так:

[yar4e@yar4e-admin ~]$ ps aux | grep X
yar4e     6888  0.0  0.0    568   144 pts/5    D+   14:39   0:00 grep X
root      7324  0.0  0.9  42356 19852 tty7     Ss+  Mar26  26:19 X :0 vt7 -auth /var/run/xauth/A:0-uyXr3I

Всё вышеописанное реализовывалось на Alt Linux P7 TDE и может незначительно отличаться на вашем дистре.

Автор: Yar4e

Монтирование дисков средствами Systemd.

Предисловие.

С переходом дистрибутивов Linux на Systemd, мы не редко сталкиваемся с особенностями/багами реализации в этой системе инициализации той или иной привычной нам вещи. Хоть Systemd и пытается сохранять совместимость с привычными нам способами настройки системы, но часто в итоге получается не так всё красиво, как на картинке. В данной заметке, речь пойдёт о том, как в Systemd взаимодействует с файлом /etc/fstab, почему сетевые диски, прописанные в этом файле раньше монтировались, а с приходом новой системы инициализации перестали и рассмотрим родной, для Systemd, способ монтирования дисков.

Всё ниже описанное актуально для Systemd 201 и и основанного на нём дистрибутива Alt Linux P7. Так как Systemd ещё находится в фазе активной разработки, то со временем исправят описанные баги и изменят/добавят опции или синтаксис (или уже возможно что-то изменилось, так как текущая версия Systemd — 216), но в общем информация будет полезна. Читать

CPU1: not responding.

Увидел я сегодня такой замечательный глюк после установки Alt Linux P7: CPU1: not responding и перезагрузка сразу после меню GRUB. До этого стоял Alt Linux P5, на котором были другие проблемы, но такого глюка не было 🙂 Полтора часа мучил настройки BIOS, сначала изменяя все опции связанные с CPU (логика), потом с памятью (попытка найти логику), а потом и вообще все подряд опции (метод научного тыка), и… и логика проиграла! Дело было в активированных опциях USB Keyboard Support и USB Mouse Support, отключение которых решило проблему! о_О Да, да ДА!!! И это не совпадение! Я несколько раз проверил, не совпало ли это действие с расположением звёзд на небе или фазой Луны и Нет — именно эти опции были причиной проблемы.. В общем, я считаю что это знание должно быть разделено с русскоязычным интернетом и должно сэкономить другим товарищам по несчастью часть нервных клеток 🙂 Времени выяснять, в версии BIOS дело, уровне поддержки данного железа ядром Linux или в криворукости собиравшего систему — не было, поэтому просто делюсь информацией, как есть. Конфиг ПК:
ПО: Alt Linux P7 TDE, с обновлённый пакетной базой.
Железо: Intel(R) Core(TM)2 CPU E8400 @ 3.00GHz (fam: 06, model: 17, stepping: 0a), Gigabyte G33M-DS2R.

Автор: Yar4e

Начало работы

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

Например, есть большая разница, если сравнить работу на Pentium 2 и на другом 4-х ядерном ПК. Понятное дело, что пентиум второй при использовании современных программ будет очень часто зависать и вообще никак не потянет загрузку оконной оболочки калькулятора. Я уже молчу о вычислении 2+2 🙂

ПК, которые имеют 4-х ядерный процессор более работоспособны и для разработки приложений профессионалы используют именно такой тип оборудования, или мощнее.

Но это не всё. Также важную роль играет и программное обеспечение, которое установлено. Самым главным является ОС. (операционная система) 
Лично я пробовал шесть ОС, из них долгое время отработал на трёх. Среди них Ubuntu (и её другие модификации как XUbuntu, KUbuntu…), OpenSuse, LinuxMint, Windows (xp и 7), AltLinux (вот это вот не посоветовал бы), ну и конечно же MacOS.

Из всего перечисленного в работе побывал Windows, Ubuntu (стандартная, gnome), в данный момент практикую MacOs и буду дальше работать только с ним, надеюсь.

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

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

Ну и на самом дне конечно же виндовс. При том любой. Хоть ХР, хоть седьмой — разница есть, разве что в дизайне, а так это «макаронное решето» для вирусов. А вирусы настолько малы, что их в микроскоп не всегда видно… Поэтому можно сделать вывод, что наличие данного решета как то бесполезно. Что с ним, что без него — одинаково. Иди и ломай.

Вера в Касперского

Народ в общей массе, установив данный не бесплатный продукт становится полностью уверен, что никакие вредоносные программы больше не смогут попасть в систему. Но свойственно это ламерам, как правило. Если вам не известна система работы антивирусника, то расскажу вкратце:
Есть вирус, его поймала «лаборатория Касперского» (звучит эффектно), которая занимается изучением вируса (возможно декомпиляция и тд). Затем из программного кода вируса, который увидели, делают выводы, алгоритм ликвидации вируса а также всей его проделанной работы, насколько это возможно. Затем вирус добавляется в базу данных касперского. Только после этой процедуры наш любимый Антивирусник умеет удалять вирус той версии, которая попадала в лабораторию. Следовательно, если вирус не был в лаборатории, то он не будет пойман!

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

Там ещё много интересного, но боюсь, что этого достаточно, чтобы не работать с виндовсом.
Лично я, практикуя MacOs устанавливаю виртуальный виндовс, через который запускаю какие либо программы, аналог которых нету в других ОС. Соблюдая правило «не ходить в интернет через виндовс на те сайты, где над