<?xml version="1.0" encoding="utf-8"?> 
<rss version="2.0"
  xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
  xmlns:atom="http://www.w3.org/2005/Atom">

<channel>

<title>Копытов Иван: заметки с тегом исправление</title>
<link>https://www.kini24.ru/tags/ispravlenie/</link>
<description>Блог ленивого сисадмина</description>
<author></author>
<language>ru</language>
<generator>Aegea 11.3 (v4134)</generator>

<itunes:subtitle>Блог ленивого сисадмина</itunes:subtitle>
<itunes:image href="" />
<itunes:explicit></itunes:explicit>

<item>
<title>Перенос Windows на новое железо</title>
<guid isPermaLink="false">221</guid>
<link>https://www.kini24.ru/all/perenos-windows-na-novoe-zhelezo/</link>
<pubDate>Tue, 02 Oct 2018 10:42:11 +0700</pubDate>
<author></author>
<comments>https://www.kini24.ru/all/perenos-windows-na-novoe-zhelezo/</comments>
<description>
&lt;p&gt;Жене надоело, что компьютер постоянно выключается, попросила меня или починить его или перенести все данные на ноутбук, который я по лету сдавал в ремонт, но так и не добрался его проверить. Поработав с компьютером, пришел к заключению, что виной внезапных отключений является блок питания. Посмотрел характеристики ноутбука — оказалось, что он намного мощней компьютера, поэтому предпочел перенести систему на него. Но железо этих двух компьютеров сильно различалось, поэтому обойтись «малой» кровью не удалось. К счастью в интернете  на сайте «мелкомягких» попалась статья, где подробно разъяснялось как это сделать при помощи программы Sysprep. Попробовал — все прошло успешно. Ровно до того момента, пока я не вставил жесткий диск в ноутбук. Система просто отказалась загружаться. Точнее будет сказать, что она загружалась, но на одном из этапов подготовки к работе сообщала, что у нее не получается его выполнить и, мол, давай перезагрузимся. И так по кругу.&lt;br /&gt;
Дальнейший поиск в интернете показал, что одной из причин такого  поведения может быть антивирус. И верно, я его не удалял перед подготовкой системы к переносу. И корректно удалить его уже не получится. Хм, если не получается «по хорошему», будем пробовать «по плохому». Удалил папки с файлами антивируса, внес изменения в реестр, перезагрузил ноутбук. На этот раз все этапы были завершены корректно.&lt;br /&gt;
Но это были «мелочи», по сравнению со следующими проблемами. Старая проблема с видеокартой осталась: при установке драйверов на Windows 7 x64 система «падала» в BSOD. При этом, работая в Linux на этом ноутбуке, проблем не возникало.&lt;br /&gt;
На следующий день, уже на работе, решил попробовать другую ОС. Поставил «десятку», несмотря на мое крайне плохое к ней отношение. После того, как она скачала и установила драйверы для видеокарты, Windows снова «словила» BSOD. Перезагрузила ноутбук и попробовала исправить проблему. Так как я уже потерял надежду, что проблем с ноутбуком не будет, то не стал прерывать процесс. Неожиданно, но после очередной перезагрузки система заработала. Зашел в диспетчер устройств, посмотрел на используемый драйвер для видеокарты — нет, не стандартный, а ATI. Хм, интересно...&lt;br /&gt;
В общем, система пока ставит все обновления, потом буду накатывать все нужные программы.&lt;/p&gt;
</description>
</item>

<item>
<title>Дело движется</title>
<guid isPermaLink="false">209</guid>
<link>https://www.kini24.ru/all/delo-dvizhetsya/</link>
<pubDate>Thu, 16 Aug 2018 14:45:57 +0700</pubDate>
<author></author>
<comments>https://www.kini24.ru/all/delo-dvizhetsya/</comments>
<description>
&lt;h3&gt;В продолжение предыдущей заметки&lt;/h3&gt;
&lt;p&gt;«Облако» было починено очень просто — изменением прав доступа к каталогу с файлами. Следом возникла другая ошибка — невозможность загрузить любой файл в него. Логи показали, что в этом повинен модуль защиты, который не пропускал файлы размером более 128 Кб. Исправил.&lt;br /&gt;
Зеркало баз NOD32, к сожалению, пока что починить не получилось. Но, похоже, что я наткнулся на возможную причину некорректной проверки ключей. Надо списаться с автором скрипта.&lt;br /&gt;
Еще один момент, который я поначалу упустил из вида: сервер с контактами и задачами. С ним пришлось повозиться. В итоге все дело оказалось в том, что php-fpm не передает заголовки авторизации и, соответственно, не отправляет данные (логин пользователя и пароль). Этот момент оказался описан в документации к baikal, поэтому на исправление ошибки ушло немного времени. Возможно, что примерно такая же ситуация обстоит и с проверкой ключей NOD32 на их серверах.&lt;br /&gt;
Должен отметить, что связка apache-mpm-worker + FastCGI меня очень радует скоростью работы. Если раньше при работе с клиентом Nextcloud на телефоне приходилось ждать пока обновится/загрузится содержимое каталога, то теперь это происходит едва не мгновенно. Видимо, сказывается «тлетворное» влияние HTTP/2 :-)&lt;/p&gt;
</description>
</item>

<item>
<title>Ошибка в транспорте mrim</title>
<guid isPermaLink="false">123</guid>
<link>https://www.kini24.ru/all/oshibka-v-transporte-mrim/</link>
<pubDate>Thu, 16 Nov 2017 10:43:59 +0700</pubDate>
<author></author>
<comments>https://www.kini24.ru/all/oshibka-v-transporte-mrim/</comments>
<description>
&lt;p&gt;После обновления системы и перезагрузки сервера транспорт агента mail.ru не «завелся». После недолгих поисков обнаружилось, что Openfire по какой-то причине слушает порты по TCPv6, а на «четверку» он забил. Пришлось внести маленькую корректировку в файл конфигурации mrim.conf:&lt;/p&gt;
&lt;pre class="e2-text-code"&gt;&lt;code class=""&gt;server = 127.0.0.1&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;заменить на&lt;/p&gt;
&lt;pre class="e2-text-code"&gt;&lt;code class=""&gt;server = localhost&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Ключ -d тоже не сработал, пришлось снова перезагружать сервер для запуска транспорта. Надо как-то это исправить — не буду же я каждый раз для перезапуска транспорта перезагружать систему.&lt;/p&gt;
</description>
</item>

<item>
<title>Syslog. Продолжаем наблюдение</title>
<guid isPermaLink="false">97</guid>
<link>https://www.kini24.ru/all/syslog-prodolzhaem-nablyudenie/</link>
<pubDate>Tue, 03 Oct 2017 17:43:19 +0700</pubDate>
<author></author>
<comments>https://www.kini24.ru/all/syslog-prodolzhaem-nablyudenie/</comments>
<description>
&lt;p&gt;Наблюдение показало, что «валится» syslogd в очень определенное время — в момент окончания работы logrotate. Пройдя через цепочку файлов, наткнулся на упоминание reload-syslog в папке /sbin. Полез посмотреть что это за файл, а он представляет собой обычный скрипт, в котором есть такая строчка:&lt;/p&gt;
&lt;pre class="e2-text-code"&gt;&lt;code class=""&gt;/sbin/service $n reload &amp;amp;&amp;amp; break&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Мелькнула «шальная» мысль, которая заставила меня заменить &lt;i&gt;reload&lt;/i&gt; на &lt;i&gt;restart&lt;/i&gt;. Следом я удалил скрипт, который перезапускал syslogd через 1 час, после того, как он «вешался». День первый — полет нормальный. Продолжаем наблюдение...&lt;/p&gt;
</description>
</item>

<item>
<title>Обновление блога</title>
<guid isPermaLink="false">85</guid>
<link>https://www.kini24.ru/all/obnovlenie-bloga/</link>
<pubDate>Wed, 06 Sep 2017 10:43:17 +0700</pubDate>
<author></author>
<comments>https://www.kini24.ru/all/obnovlenie-bloga/</comments>
<description>
&lt;p&gt;Давно мучил вопрос почему у меня в блоге перестали вставляться картинки. После обновления блога и нескольких экспериментов выяснилось, что во всем виновата тема, которую я создал. Смена темы на стандартную позволила снова вставлять картинки. Снес все файлы блога, переустановил движок. Вернул на место картинки и... Некоторые из них не вернулись в заметки. Пришлось входить в редактирование и заново сохранять их, после этого все пришло в норму. Надеюсь, что ничего не пропустил. Если что-то найдете — напишите мне, исправлю&lt;/p&gt;
</description>
</item>

<item>
<title>Исправление ошибок</title>
<guid isPermaLink="false">73</guid>
<link>https://www.kini24.ru/all/ispravlenie-oshibok/</link>
<pubDate>Sun, 09 Jul 2017 17:15:40 +0700</pubDate>
<author></author>
<comments>https://www.kini24.ru/all/ispravlenie-oshibok/</comments>
<description>
&lt;p&gt;Уже вечером исправил косяки с новой станцией. После переброса на другую линию питания датчика ds18b20 он заработал. Это радует.&lt;br /&gt;
Также вроде бы решил проблему со скриптом отправки данных. Вместо накопления данных в нескольких файлах, размер каждого из которых не превышает 4 кБ, сделал обработу ответа «ERROR NO CHANGES». Если скрипт получает такой ответ, то просто стирается содержимое временного файла. Иными словами, он реагирует так же, как будто получил ответ «ОК». Это, конечно, не решает вопроса длительного отсутствия связи с сервером. Так что будем думать дальше.&lt;br /&gt;
Не могу пока что придумать как разместить станцию. По хорошему ее нужно разместить подальше от стены, чтобы исключить ее влияние на показания. Но тут встает вопрос как закрепить круглую металлическую трубку на стене. С другой стороны, самый простой вариант — разместить станцию, прикрутив с наружной стороны лоджии, просто на саморезы. На решение времени осталось не так уж и много — скоро наступят холода, работать будет не очень комфортно.&lt;/p&gt;
</description>
</item>


</channel>
</rss>