Skurudo Blog(post)

Заметки и замечания, рассказы и пересказы

Kyocera TWAIN: драйвер не виден после установки

Ставим драйвер сканера Kyocera (в моём случае — MX4000). Установщик честно просит права администратора, всё ставится, галочки зеленеют. Запускаем KYOCERA Quick Scan под пользователем — не работает, под обычным пользователем — «TWAIN driver не установлен». Переустанавливали несколько раз и результат один — оно не работает. А под администратором заработало...

Почему так могло получиться? Установщик Kyocera, несмотря на UAC-запрос, складывает часть настроек в профиль того пользователя, от имени которого запущен. То есть в `C:\Users\Administrator\AppData\` (или кто там у вас админ или происходит запуск с повышенными правами). Обычный пользователь эти настройки не видит — для него драйвера как бы не существует.

Самое простое решение — копировать папку с настройками из профиля админа в профиль пользователя:

C:\Users\<Админ>\AppData\Local\Kyocera\

в

C:\Users\<Пользователь>\AppData\Local\Kyocera\

Если там пусто — смотрим в `AppData\Roaming\Kyocera\`.

После копирования TWAIN-драйвер сразу появляется в списке. Даже перезагрузка не нужна.

Проблема оказалась не в правах, не в разрядности, не в сети. Установщик Kyocera хранит настройки драйвера в профиле пользователя. Установщик этого не учитывает, что драйвера нужны всем, а не только «админу». Отдельно хочу заметить, что установщик драйверов печати ведет себя корректнее :)

Открыть шлюзы

Сколько занятных вещей узнаешь с микротиками, не описать.. Одна из них — добавление шлюза или gateway. Обычно у нас шлюз в одной подсети и его добавление не вызывает никаких проблем, например:

/ip route add dst-address=0.0.0.0/0 gateway=${GATEWAY}

Но так вполне себе может не работать, если шлюз у вас из другой подсети или вообще условный 10.0.0.1. Конструкция наподобие того, что в линуксах в таких случаях будет не сработает, RouterOS так не умеет onlink.

/ip route add dst-address=0.0.0.0/0 gateway=10.0.0.1%ether1

Выход есть — использовать вариант со scope

/ip route add dst-address=10.0.0.1/32 gateway=ether1 scope=10
/ip route add dst-address=0.0.0.0/0 gateway=10.0.0.1 target-scope=11

RouterOS находит маршрут до 10.0.0.1 (scope=10, что ≤ 11), видит что он через ether1, и рекурсивно резолвит — весь трафик 0.0.0.0/0 уходит через ether1 на адрес 10.0.0.1. Мы явно сказали системе, что шлюз 10.0.0.1 живёт на ether1, не требуя чтобы он был в одной IP-подсети.

Уведомления о проблемах в Oxidized

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

Например есть довольно зрелый продукт для резервного копирования конфигурация — Oxidized. Разработка пришла на смену RANCID и заменила его чуть более чем полностью. В нем исторически есть набор фич, но развитие за годы замедлилось. Работает ведь отлично, зачем ломать? Но есть задачи немного в сторону.

В Oxidized нет возможности из коробки направить уведомлении об успешном или наоборот — не очень успешном процессе резервирования. Для этого можно использовать так называемые хуки. И вроде hook не слишком сложный, но важно помнить, что важен формат — yaml.

hooks:
  failed:
    type: exec
    events: [node_fail]
    cmd: 'echo "$OX_NODE_NAME,$OX_NODE_IP,$OX_JOB_STATUS" >> /home/oxidized/.config/oxidized/ox_node_failed.log'

На выходе мы получаем текстовый файл в формате csv и сможем еще уже отправить дальше. Например в телеграм путем не очень хитрых манипуляций:

#!/bin/bash

# Set the API token and chat ID - обозначаем токен и id чата
API_TOKEN="token"
CHAT_ID="chat-id"

# Parse file with error - объявляем путь к файлу
FILE=/opt/oxidized/ox_node_failed.log

# Checking if file is empty or not - проверяем, пустой ли файл
if [ -s $FILE ]
then
     echo "File is not empty, do the JOB"

       # Read file, prepare messade and send to Telegram - читаем файл, готовим сообщение и отправляем
        while IFS=, read -r col1 col2 col3
        do
            MESSAGE=("<b>ERROR DETECTED</b> while backup on device $col1 with IP: $col2 reason: <b>$col3</b>. Check <a href=\"http://oxidized.url\">Oxidized</a>!");
            echo $MESSAGE

        # Use the curl command to send the message - отправляем сообщение
        curl -s -X POST https://api.telegram.org/bot$API_TOKEN/sendMessage -d parse_mode="html" -d chat_id=$CHAT_ID -d text="$MESSAGE";

        done < $FILE
      
        # Clean file - очищаем файл, чтобы избежать повторной отправки
        >$FILE

else
     echo "File is empty, nothing to do"
     exit;
fi

Теперь и на Github! ^_^

Лагерь курильщиков

Подсмотрено на территории одного учебного заведения — натуральный лагерь для курильщиков:

Цифровые нужды в нужнике

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

Мне вспомнилось, что желание удовлетворять потребности не только физиологические, но и, так сказать, цифровые появилось даже не с момента появления смартфонов и планшетов. Еще во времена FIDO, когда интернет был модемным, желающие читать конференции вместе с фаянсовым другом находились. Практическая реализация подводила, но стойкое желание было. Future is now. Прогресс победил и теперь можно :)

Про обзывания серверов

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

Из веселых историй из жизни можно вспомнить буквально две.. в одной организации, которая занималась градостроительными проектами называли малыми городами России — брались города малоизвестные и с небольшим населением. :)

Вишенка в торте и, к сожалению, не моя придумка, а Системного Архитектора — называл он серверы терминами из порно. Там было буквально все — cumshot, bigcocks, asshole, whore, blowjob, ebony... Начальство как-то не «дочухало» до названий, с английским, особенно со сленгом, в начале нулевых было не так, чтобы шибко хорошо. Сообщения друг другу и «алерты» вроде: «whore умерла, что-то не отзывается», «проблемы с камшотом», «восстановите бигкокс» — даже сейчас вызывают легкую улыбку :)

Ранее Ctrl + ↓