⭐️ Ставьте лайки, подписывайтесь на канал, заносите обратную связь и, конечно же, пользуйтесь на здоровье с учетом законодательства той страны, в которой живете :)<\/p>\n", "date_published": "2026-03-04T11:28:53+03:00", "date_modified": "2026-03-04T11:29:44+03:00", "tags": [ "Mikrotik" ], "_date_published_rfc2822": "Wed, 04 Mar 2026 11:28:53 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "267", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "266", "url": "https:\/\/skurudo.ru\/all\/kyocera-twain-drivers-install-problem\/", "title": "Kyocera TWAIN: драйвер не виден после установки", "content_html": "
Ставим драйвер сканера Kyocera (в моём случае — MX4000). Установщик честно просит права администратора, всё ставится, галочки зеленеют. Запускаем KYOCERA Quick Scan под пользователем — не работает, под обычным пользователем — «TWAIN driver не установлен». Переустанавливали несколько раз и результат один — оно не работает. А под администратором заработало...<\/p>\n
Почему так могло получиться? Установщик Kyocera, несмотря на UAC-запрос, складывает часть настроек в профиль того пользователя, от имени которого запущен. То есть в `C:\\Users\\Administrator\\AppData\\` (или кто там у вас админ или происходит запуск с повышенными правами). Обычный пользователь эти настройки не видит — для него драйвера как бы не существует.<\/p>\n
Самое простое решение — копировать папку с настройками из профиля админа в профиль пользователя:<\/p>\n
C:\\Users\\<Админ>\\AppData\\Local\\Kyocera\\<\/code><\/pre>в<\/p>\n
C:\\Users\\<Пользователь>\\AppData\\Local\\Kyocera\\<\/code><\/pre>Если там пусто — смотрим в `AppData\\Roaming\\Kyocera\\`.<\/p>\n
После копирования TWAIN-драйвер сразу появляется в списке. Даже перезагрузка не нужна.<\/p>\n
Проблема оказалась не в правах, не в разрядности, не в сети. Установщик twain-драйверов Kyocera хранит настройки драйвера в профиле пользователя. Он не учитывает, что драйвера нужны всем, а не только «админу». Отдельно хочу заметить, что установщик драйверов печати ведет себя корректнее :)<\/p>\n",
"date_published": "2026-02-05T09:32:50+03:00",
"date_modified": "2026-02-06T02:23:46+03:00",
"tags": [
"Kyocera",
"Windows"
],
"_date_published_rfc2822": "Thu, 05 Feb 2026 09:32:50 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "266",
"_e2_data": {
"is_favourite": false,
"links_required": [
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "265",
"url": "https:\/\/skurudo.ru\/all\/open-gateways\/",
"title": "Открыть шлюзы",
"content_html": "
Сколько занятных вещей узнаешь с микротиками, не описать.. Одна из них — добавление шлюза или gateway. Обычно у нас шлюз в одной подсети и его добавление не вызывает никаких проблем, например:<\/p>\n
\/ip route add dst-address=0.0.0.0\/0 gateway=${GATEWAY}<\/code><\/pre>Но так вполне себе может не работать, если шлюз у вас из другой подсети или вообще условный 10.0.0.1. Конструкция наподобие того, что в линуксах в таких случаях будет не сработает, RouterOS так не умеет onlink.<\/p>\n
\/ip route add dst-address=0.0.0.0\/0 gateway=10.0.0.1%ether1<\/code><\/pre>Выход есть — использовать вариант со scope<\/p>\n
\/ip route add dst-address=10.0.0.1\/32 gateway=ether1 scope=10\r\n\/ip route add dst-address=0.0.0.0\/0 gateway=10.0.0.1 target-scope=11<\/code><\/pre>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-подсети.<\/p>\n",
"date_published": "2026-02-03T07:51:39+03:00",
"date_modified": "2026-02-03T12:28:45+03:00",
"tags": [
"Mikrotik",
"RouterOS"
],
"_date_published_rfc2822": "Tue, 03 Feb 2026 07:51:39 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "265",
"_e2_data": {
"is_favourite": false,
"links_required": [
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "264",
"url": "https:\/\/skurudo.ru\/all\/notifications-about-problems-in-oxidized\/",
"title": "Уведомления о проблемах в Oxidized",
"content_html": "
Разбор не сильно освещенных мест в довольно популярных продуктах несет с собой некоторое количество боли. Разработчики пишут документацию, считая некоторые вещи очевидными, но так бывает довольно не всегда и примеров с конфигурациями частенько бывает не хватает. В случае же с блогерами все тоже довольно грустно. Обзоры похожи один на другой и никто не старается копнуть вглубь и предложить что-то интересное или необычное.<\/p>\n
Например есть довольно зрелый продукт для резервного копирования конфигурация — Oxidized. Разработка пришла на смену RANCID и заменила его чуть более чем полностью. В нем исторически есть набор фич, но развитие за годы замедлилось. Работает ведь отлично, зачем ломать? Но есть задачи немного в сторону.<\/p>\n
В Oxidized нет возможности из коробки направить уведомлении об успешном или наоборот — не очень успешном процессе резервирования. Для этого можно использовать так называемые хуки. И вроде hook не слишком сложный, но важно помнить, что важен формат — yaml.<\/p>\n
hooks:\r\n failed:\r\n type: exec\r\n events: [node_fail]\r\n cmd: 'echo "$OX_NODE_NAME,$OX_NODE_IP,$OX_JOB_STATUS" >> \/home\/oxidized\/.config\/oxidized\/ox_node_failed.log'<\/code><\/pre>На выходе мы получаем текстовый файл в формате csv и сможем еще уже отправить дальше. Например в телеграм путем не очень хитрых манипуляций:<\/p>\n
#!\/bin\/bash\r\n\r\n# Set the API token and chat ID - обозначаем токен и id чата\r\nAPI_TOKEN="token"\r\nCHAT_ID="chat-id"\r\n\r\n# Parse file with error - объявляем путь к файлу\r\nFILE=\/opt\/oxidized\/ox_node_failed.log\r\n\r\n# Checking if file is empty or not - проверяем, пустой ли файл\r\nif [ -s $FILE ]\r\nthen\r\n echo "File is not empty, do the JOB"\r\n\r\n # Read file, prepare messade and send to Telegram - читаем файл, готовим сообщение и отправляем\r\n while IFS=, read -r col1 col2 col3\r\n do\r\n 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>!");\r\n echo $MESSAGE\r\n\r\n # Use the curl command to send the message - отправляем сообщение\r\n curl -s -X POST https:\/\/api.telegram.org\/bot$API_TOKEN\/sendMessage -d parse_mode="html" -d chat_id=$CHAT_ID -d text="$MESSAGE";\r\n\r\n done < $FILE\r\n \r\n # Clean file - очищаем файл, чтобы избежать повторной отправки\r\n >$FILE\r\n\r\nelse\r\n echo "File is empty, nothing to do"\r\n exit;\r\nfi<\/code><\/pre>
![\"\"](\"https:\/\/skurudo.ru\/pictures\/image-6.png\")
\n<\/div>\n",
"date_published": "2024-07-02T14:34:39+03:00",
"date_modified": "2024-07-02T14:34:29+03:00",
"tags": [
"дневник"
],
"image": "https:\/\/skurudo.ru\/pictures\/image-6.png",
"_date_published_rfc2822": "Tue, 02 Jul 2024 14:34:39 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "263",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/skurudo.ru\/pictures\/image-6.png"
]
}
},
{
"id": "262",
"url": "https:\/\/skurudo.ru\/all\/toilet-stories\/",
"title": "Цифровые нужды в нужнике",
"content_html": "![\"\"](\"https:\/\/skurudo.ru\/pictures\/image-5.png\")
\n<\/div>\n![\"\"](\"https:\/\/skurudo.ru\/pictures\/2024-01-09-13-38-15.JPG\")
\n<\/div>\n",
"date_published": "2024-04-04T14:50:01+03:00",
"date_modified": "2024-04-04T14:49:02+03:00",
"tags": [
"дневник"
],
"image": "https:\/\/skurudo.ru\/pictures\/2024-01-09-13-38-15.JPG",
"_date_published_rfc2822": "Thu, 04 Apr 2024 14:50:01 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "260",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/skurudo.ru\/pictures\/2024-01-09-13-38-15.JPG"
]
}
},
{
"id": "259",
"url": "https:\/\/skurudo.ru\/all\/v-under-ninja-vrat-ne-budut\/",
"title": "В Under Ninja врать не будут :)",
"content_html": "![\"\"](\"https:\/\/skurudo.ru\/pictures\/__2023-11-10_003.jpg\")
\n<\/div>\n