Виктор Судаков

Насколько я понял, существует 3 способа подключить Google Calendar от моей учетной записи Google к календарю Thunderbird.

1. Завести в Thunderbird мою почту Gmail, в этом случае календари и задачи Google подключатся автоматически. Я этот способ не пробовал, так как я не использую Thunderbird для Gmail и не собираюсь. Для полноты информации привожу последовательность действий.

2. Использовать дополнение к Thunderbird "Provider for Google Calendar". К сожалению оно довольно кривое, имеет проблемы с синхронизацией задач и другие проблемы, в частности в подключенный таким образом Google Calendar нельзя добавить приглашение на встречу из E-mail, возникает ошибка "No writable calendars are configured for invitations, please check the calendar properties". Календарь при этом точно не Read Only, потому что обычным способом в него добавить событие можно.

3. Третий способ подсмотрен в https://support.mozilla.org/en-US/questions/1304356#answer-1368791

You can add a Google calendar to TB without add-ons, as a CalDAV calendar, by entering this for the Location:

https://apidata.googleusercontent.com/caldav/v2/myname@gmail.com/events

Enter your email address for the Username, and allow cookies in Options/Privacy & Security, for OAuth2 authentication.

К сожалению, третий способ не позволяет синхронизировать задачи (Google Tasks) с Thunderbird. Может кто знает, как добавить синхронизацию задач к третьему способу?

UPD 4. Есть еще описание на https://support.mozilla.org/ru/kb/sozdanie-novyh-kalendarej#w_v-seti-podkliuchenie-k-onlain-kalendariam , где говорится, как включить доступ к календарю по ссылке и скопировать эту ссылку. К сожалению данный способ тоже не даёт доступа к Задачам.

Вы обратили внимание, что улицы на панорамах Яндекс Карт причудливым образом искажены? Создается впечатление, что улица делает плавный поворот или изгиб, тогда как на самом деле она на этом участке совершенно прямая (я-то знаю, какая она на самом деле, полвека живу в Томске).

На панорамах Google Maps подобного безумного эффекта нет: крути панораму как хочешь, прямая улица и останется прямой.

Сервис проверки лотерейных билетов "Столото" по QR-коду (http://stolo.to/qr бла бла) уже третий день не работает c "504 Gateway Time-out". Стыд однако.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241474
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241475
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241531
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241684

И пятая проблема, связанная с autofs частично (карта special_media использует fstyp):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242225

FreeBSD и съемные носители изначально не дружат... 21 век на дворе, стыдно.

Кто бы ещё подсказал, как оторвать начисто автомонтирование в mate, которое всё время путается под ногами.

Алгоритм взаимодействия apcupsd с системой при её выключении не менялся уже 17 лет. По умолчанию apcupsd запускается с ключом --kill-on-powerfail, что означает: при исчерпании заряда аккумулятора в ИБП, послать ИБП команду "уснуть" и одновременно запустить процедуру doshutdown из /usr/local/etc/apcupsd/apccontrol. В ИБП обычно предусмотрена задержка (так называемый grace delay) 10-40 секунд исполнения команд "выключиться" и "уснуть". В этом месте начинается race: что случится раньше, shutdown успеет корректно завершиться или ИБП выключится?

В прежние времена, наверное, это всех устраивало, потому что выключение системы проходило быстро и shutdown успевал всё завершить до выключения питания. Хотя напомню, что значение по умолчанию rcshutdown_timeout="90" заведомо больше grace delay любого ИБП. Так что race condition никуда не девался на самом деле.

В нынешнее время с распространением виртуальных машин во время выключения хоста включено время выключения виртуалок, которое может быть весьма значительным. Я например устаналиваю rcshutdown_timeout="240" и kern.init_shutdown_timeout="300" и то виндовые VM выключиться не успевают. Понятно, что в UPS grace delay не укладываемся точно.

Поэтому предлагаю новый алгоритм выключения системы посредством apcupsd, и открыл на эту тему ПР https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237600 Суть нового (не очень нового, на самом деле, в Linux используется подобный) алгоритма:

Запускаем apcupsd с ключом --term-on-powerfail

apcupsd_enable="YES"
apcupsd_flags="--term-on-powerfail"

это значит после запуска процедуры shutdown и создания флага /var/run/powerfail apcupsd должен выйти и не путаться пока под ногами.

А в конце /etc/rc.shutdown вписываем строчку

test -f /var/run/powerfail && /usr/local/sbin/apcupsd --hibernate

или

test -f /var/run/powerfail && /usr/local/sbin/apcupsd --power-off

(кому как удобнее, в зависимости от требуемого поведения ИБП после восстановления питания).

Это означает, что только после отработки всех rc.d скриптов с параметром stop в ИБП будет послана команда "уснуть" или "выключиться" соответственно.

UPD A brief summary in English.

My final conclusion. The default way apcupsd is started by the port (with --kill-on-powerfail) is wrong. You cannot rely on the UPS grace shutdown delay even with the default setting of rcshutdown_timeout="90", while using virtual machines necessitates making rcshutdown_timeout even longer. A race between the UPS grace delay and the FreeBSD shutdown procedure must be eradicated.

The only feasible way of doing it is:

1. Starting apcupsd with apcupsd_flags="--term-on-powerfail" so that the daemon exits once it has started the doshutdown procedure and does not send any commands to the UPS at this stage.

2. Putting the line

"test -f /var/run/powerfail && /usr/local/sbin/apcupsd --hibernate"

or

"test -f /var/run/powerfail && /usr/local/sbin/apcupsd --power-off"

(depending on the desired behaviour of the UPS after the mains is restored) at the very end of the /etc/rc.shutdown script, after the "Insert other shutdown procedures here" line.

Thus the shutdown procedure started by "apcupsd --term-on-powerfail" can proceed at its own tempo, with "apcupsd --hibernate" being called when all the daemons and VMs have been safely shut down.

UPD 2. Ещё предлагают такой способ: http://www.wfido.ru/m/RU.UNIX.BSD/grosbein.net+c3b53b4f который призван исключить достаточно маловероятную, но неприятную ситуацию, если питание успело восстановиться после завершения apcupsd, но до killpower.

1. При попытке загрузить в Drupal 8 модули или темы через админский веб-интерфейс возникает приглашение ввести учетные данные для доступа к коду сайта по FTP (!).

Решение (при условии, что пул php-fpm работает от пользователя www):

chown -R www:www /usr/local/www/drupal8/modules /usr/local/www/drupal8/themes

2. При попытке загрузить в Drupal 8 модули или темы через админский веб-интерфейс возникает "AJAX HTTP ошибка, полученный код HTTP 403" с невнятным упоминанием "/core/authorize.php/core/authorize.php?batch=1...". Это значит, вы делали настройку связки drupal+nginx+php-fpm по статье https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/ , но натолкнулись на баг, описанный в https://pantheon.io/blog/update-your-nginx-config-drupal-8. Но решение в тексте статьи описано неправильно, правильное решение есть в комментах, и заключается в строчке

rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1;
прямо в блоке server{} перед 
   location ~ \..*/.*\.php$ {
        return 403;
    }

Ночью в пятницу свичи
Превратились в кирпичи.
Смотришь в конфиг - как же так?
В "show start" пиндосский флаг.

Тут админы у свичей
Принимая корвалол
Отложили кирпичей
На хороший firewall.

Не могу по случаю не вспомнить историю про хакера и солонку: https://xakep.ru/2006/12/16/35784/

Как сделать сабж таким образом, чтобы коммит-логи (в кодировке koi8-r) нормально перенеслись в hg? Возможно что-то надо написать в .hgrc, но что именно?

Гугление не очень помогло. Есть намеки, что cvsps можно пропустить через pipe, но не понял как.

UPD

Пришлось перекодировать весь CVS репозиторий в UTF-8, выставить локале ru_RU.UTF-8 и после этого уже запускать "hg convert". А потом перекодировать файлы в рабочей копии обратно в KOI8-R и коммитить это как изменение.

UPD2

https://bz.mercurial-scm.org/show_bug.cgi?id=5597

UPD2

Один японец написал hook, который проблему решает: https://bitbucket.org/foozy/hghook-cvslog-transcoder/overview Я проверил - работает.

news/husky-sqpack теперь в официальном дереве портов. Мелочь, а приятно.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200481

Интересен не баг сам по себе, а то что найден котом :-) https://bugzilla.gnome.org/show_bug.cgi?id=758032

Почему-то на FreeBSD повторить не получилось, хотя у меня gdm-3.16.2 числится как vulnerable.